Re: [PATCH v2] tools: mkimage: fix build with recent LibreSSL

[Jonathan Gray]

On Mon, Aug 29, 2022 at 01:34:01PM +0200, Mark Kettenis wrote:
> LibreSSL 3.5.0 and later (also shipped as part of OpenBSD 7.1 and
> and later) have an opaque RSA object and do provide the
> RSA_get0_* functions that OpenSSL provides.
> 
> Fixes: 2ecc354b8e46 ("tools: mkimage: fix build with LibreSSL")
> Signed-off-by: Mark Kettenis 

Reviewed-by: Jonathan Gray 

> ---
> 
> ChangeLog:
> 
> v2: - Tweak version check and commit message to reflect that
>   LibreSSL 3.5.0 and later have the RSA_get0_* functions
> 
> 
>  tools/sunxi_toc0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/sunxi_toc0.c b/tools/sunxi_toc0.c
> index 56200bd927..7a8d74bb8e 100644
> --- a/tools/sunxi_toc0.c
> +++ b/tools/sunxi_toc0.c
> @@ -34,7 +34,7 @@
>  #define pr_warn(fmt, args...)fprintf(stderr, pr_fmt(fmt), "warning", 
> ##args)
>  #define pr_info(fmt, args...)fprintf(stderr, pr_fmt(fmt), "info", 
> ##args)
>  
> -#if defined(LIBRESSL_VERSION_NUMBER)
> +#if defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x305fL
>  #define RSA_get0_n(key) (key)->n
>  #define RSA_get0_e(key) (key)->e
>  #define RSA_get0_d(key) (key)->d
> -- 
> 2.37.2
> 
> 

Re: [PATCH] tools: mkimage: fix build with recent LibreSSL

[Jonathan Gray]

On Sat, Aug 27, 2022 at 07:23:44PM +0200, Mark Kettenis wrote:
> Recent versions of LibreSSL, such as those shipped as part of
> OpenBSD 7.1 and later have an opaque RSA object and do provide the
> RSA_get0_* functions that OpenSSL provides.

part of 3.5.0 / 0x305fL as well
https://lists.denx.de/pipermail/u-boot/2022-July/489768.html
https://marc.info/?l=libressl=164572407401570=2

> 
> Fixes: 2ecc354b8e46 ("tools: mkimage: fix build with LibreSSL")
> Signed-off-by: Mark Kettenis 
> ---
>  tools/sunxi_toc0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/sunxi_toc0.c b/tools/sunxi_toc0.c
> index 56200bd927..eb5626411c 100644
> --- a/tools/sunxi_toc0.c
> +++ b/tools/sunxi_toc0.c
> @@ -34,7 +34,7 @@
>  #define pr_warn(fmt, args...)fprintf(stderr, pr_fmt(fmt), "warning", 
> ##args)
>  #define pr_info(fmt, args...)fprintf(stderr, pr_fmt(fmt), "info", 
> ##args)
>  
> -#if defined(LIBRESSL_VERSION_NUMBER)
> +#if defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x3050100fL
>  #define RSA_get0_n(key) (key)->n
>  #define RSA_get0_e(key) (key)->e
>  #define RSA_get0_d(key) (key)->d
> -- 
> 2.37.2
> 
> 

Re: [PATCH] tools: mkimage: fix build with LibreSSL

[Jonathan Gray]

On Fri, Jul 22, 2022 at 07:55:53PM +0200, Michal Vasilek wrote:
> RSA_get0_* functions are not available in LibreSSL

added in January


revision 1.41
date: 2022/01/05 20:44:12;  author: tb;  state: Exp;  lines: +55 -1;  commitid: 
b1ATkp4OhzL5p4XV;
Prepare to provide a number of RSA accessors

This adds RSA_get0_{n,e,d,p,q,dmp1,dmq1,iqmp,pss_params}() which will
be exposed in the upcoming bump.

ok inoguchi jsing


seems to be >= 3.5.0 for the portable releases
https://marc.info/?l=libressl=164572407401570=2

> 
> Signed-off-by: Michal Vasilek 
> ---
>  tools/sunxi_toc0.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/sunxi_toc0.c b/tools/sunxi_toc0.c
> index bab5d17b7d..56200bd927 100644
> --- a/tools/sunxi_toc0.c
> +++ b/tools/sunxi_toc0.c
> @@ -34,6 +34,12 @@
>  #define pr_warn(fmt, args...)fprintf(stderr, pr_fmt(fmt), "warning", 
> ##args)
>  #define pr_info(fmt, args...)fprintf(stderr, pr_fmt(fmt), "info", 
> ##args)
>  
> +#if defined(LIBRESSL_VERSION_NUMBER)
> +#define RSA_get0_n(key) (key)->n
> +#define RSA_get0_e(key) (key)->e
> +#define RSA_get0_d(key) (key)->d
> +#endif
> +
>  struct __packed toc0_key_item {
>   __le32  vendor_id;
>   __le32  key0_n_len;
> -- 
> 2.37.1
> 
> 

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Jonathan Gray]

On Wed, Jul 28, 2021 at 09:04:33PM +0300, Artem Panfilov wrote:
> Fix LibreSSL compilation for versions before v2.7.0.

Why 2.7.0?  I had to disable CONFIG_FIT_SIGNATURE to get the qemu
targets to build on OpenBSD-current (3.4.0) as there is no
BN_bn2binpad().  2.7.0 is also over three years old at this point.

> 
> Fix following compilation issue when CONFIG_TOOLS_LIBCRYPTO is enabled:
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function `prepare_ctx':
> ecdsa-libcrypto.c:(.text+0x94): undefined reference to
> `OPENSSL_init_ssl'
> ecdsa-libcrypto.c:(.text+0x148): undefined reference to
> `EC_GROUP_order_bits'
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function
> `ecdsa_check_signature.isra.0':
> ecdsa-libcrypto.c:(.text+0x32c): undefined reference to `ECDSA_SIG_set0'
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_sign':
> ecdsa-libcrypto.c:(.text+0x42c): undefined reference to `ECDSA_SIG_get0'
> ecdsa-libcrypto.c:(.text+0x443): undefined reference to `BN_bn2binpad'
> ecdsa-libcrypto.c:(.text+0x455): undefined reference to `BN_bn2binpad'
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_add_verify_data':
> ecdsa-libcrypto.c:(.text+0x5fa): undefined reference to
> `EC_GROUP_order_bits'
> ecdsa-libcrypto.c:(.text+0x642): undefined reference to
> `EC_POINT_get_affine_coordinates'
> 
> Signed-off-by: Artem Panfilov 
> ---
>  lib/ecdsa/ecdsa-libcrypto.c | 80 -
>  1 file changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/ecdsa/ecdsa-libcrypto.c b/lib/ecdsa/ecdsa-libcrypto.c
> index 1757a14562..50aa093acd 100644
> --- a/lib/ecdsa/ecdsa-libcrypto.c
> +++ b/lib/ecdsa/ecdsa-libcrypto.c
> @@ -24,6 +24,70 @@
>  #include 
>  #include 
>  
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
> +#include 
> +
> +static int EC_GROUP_order_bits(const EC_GROUP *group)
> +{
> + int ret = 0;
> + BIGNUM *order;
> +
> + if (!group)
> + return ret;
> +
> + order = BN_new();
> +
> + if (!order) {
> + ERR_clear_error();
> + return ret;
> + }
> +
> + if (!EC_GROUP_get_order(group, order, NULL)) {
> + ERR_clear_error();
> + BN_free(order);
> + return ret;
> + }
> +
> + ret = BN_num_bits(order);
> + BN_free(order);
> + return ret;
> +}
> +
> +static void ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM **pr, const 
> BIGNUM **ps)
> +{
> + if (pr != NULL)
> + *pr = sig->r;
> + if (ps != NULL)
> + *ps = sig->s;
> +}
> +
> +static int ECDSA_SIG_set0(ECDSA_SIG *sig, BIGNUM *r, BIGNUM *s)
> +{
> + if (r == NULL || s == NULL)
> + return 0;
> + BN_clear_free(sig->r);
> + BN_clear_free(sig->s);
> + sig->r = r;
> + sig->s = s;
> + return 1;
> +}
> +
> +int BN_bn2binpad(const BIGNUM *a, unsigned char *to, int tolen)
> +{
> + int n = BN_num_bytes(a);
> +
> + if (n < 0 || n > tolen)
> + return -1;
> +
> + memset(to, 0, tolen - n);
> + if (BN_bn2bin(a, to + tolen - n) < 0)
> + return -1;
> +
> + return tolen;
> +}
> +#endif
> +
>  /* Image signing context for openssl-libcrypto */
>  struct signer {
>   EVP_PKEY *evp_key;  /* Pointer to EVP_PKEY object */
> @@ -34,9 +98,18 @@ struct signer {
>  
>  static int alloc_ctx(struct signer *ctx, const struct image_sign_info *info)
>  {
> + int ret = 0;
> +
>   memset(ctx, 0, sizeof(*ctx));
>  
> - if (!OPENSSL_init_ssl(0, NULL)) {
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
> + ret = SSL_library_init();
> +#else
> + ret = OPENSSL_init_ssl(0, NULL);
> +#endif
> +
> + if (!ret) {
>   fprintf(stderr, "Failure to init SSL library\n");
>   return -1;
>   }
> @@ -285,7 +358,12 @@ static int do_add(struct signer *ctx, void *fdt, const 
> char *key_node_name)
>   x = BN_new();
>   y = BN_new();
>   point = EC_KEY_get0_public_key(ctx->ecdsa_key);
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
> + EC_POINT_get_affine_coordinates_GFp(group, point, x, y, NULL);
> +#else
>   EC_POINT_get_affine_coordinates(group, point, x, y, NULL);
> +#endif
>  
>   ret = fdt_setprop_string(fdt, key_node, "ecdsa,curve", curve_name);
>   if (ret < 0)
> -- 
> 2.25.1
> 
> 

Re: Boot failure triggered by USB on rockpro64-rk3399 and pinebook-pro-rk3399

[Jonathan Gray]

U-Boot 2020.07 worked, broken on rockpro64 by

commit 3ae64582fb8ceead4fc464cd2055eb3eaef78ccc (refs/bisect/bad)
Author: Jagan Teki 
Date:   Mon Jul 20 14:53:09 2020 +0530

rockchip: rockpro64: Enable USB3.0 Host

Enable USB3.0 Host support for RockPro64 boards.

Signed-off-by: Jagan Teki 
Reviewed-by: Kever Yang 

according to Kurt Miller who bisected this when the same problem was
encountered booting OpenBSD.  I don't have any rk3399 myself.

https://marc.info/?l=openbsd-ports=161005506031482=2
https://marc.info/?l=openbsd-ports=161012461223737=2

We ended up disabling CONFIG_USE_PREBOOT in rk3399 targets to fix
booting via non-usb as well.

On Thu, Jan 21, 2021 at 11:37:16AM +0800, Kever Yang wrote:
> Hi Vagrant,
> 
>     Do you know which version is the last version that works in this case?
> 
>     The firmware is from eMMC and it's wired for USB to affect the boot
> process.
> 
> Thanks,
> 
> - Kever
> 
> On 2021/1/21 上午8:08, Vagrant Cascadian wrote:
> > It seems rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot when usb
> > is started. It hangs indefinitely at:
> > 
> >## Flattened Device Tree blob at 01f0
> >   Booting using the fdt blob at 0x1f0
> > 
> > I have observed this also using 2020.10 on rockpro64-rk3399, though on
> > pinebook-pro-rk3399 usb does not work and so it basically avoids
> > triggering the issue.
> > 
> > Setting CONFIG_USE_PREBOOT=n in the config works around the problem,
> > though obviously by breaking usb keyboard support or booting from USB
> > devices.
> > 
> > 
> > Related bugs in Debian and manjaro:
> > 
> >https://bugs.debian.org/973323
> >https://bugs.debian.org/980434
> >
> > https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-rockpro64/-/issues/4
> > 
> > 
> > Boot log:
> > 
> > U-Boot 2021.01+dfsg-1 (Jan 17 2021 - 03:50:13 +)
> > 
> > SoC: Rockchip rk3399
> > Reset cause: POR
> > Model: Pine64 RockPro64 v2.1
> > DRAM:  3.9 GiB
> > PMIC:  RK808
> > MMC:   mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0
> > Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 
> > 256 Bytes, erase size 4 KiB, total 16 MiB
> > *** Warning - bad CRC, using default environment
> > 
> > In:serial
> > Out:   serial
> > Err:   serial
> > Model: Pine64 RockPro64 v2.1
> > Net:   eth0: ethernet@fe30
> > starting USB...
> > Bus usb@fe38: USB EHCI 1.00
> > Bus usb@fe3a: USB OHCI 1.0
> > Bus usb@fe3c: USB EHCI 1.00
> > Bus usb@fe3e: USB OHCI 1.0
> > Bus dwc3: usb maximum-speed not found
> > Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb@fe38 for devices... 1 USB Device(s) found
> > scanning bus usb@fe3a for devices... 1 USB Device(s) found
> > scanning bus usb@fe3c for devices... 1 USB Device(s) found
> > scanning bus usb@fe3e for devices... 1 USB Device(s) found
> > scanning bus dwc3 for devices... 1 USB Device(s) found
> > scanning usb for storage devices... 0 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > => printenv preboot
> > preboot=usb start
> > => usb reset
> > resetting USB...
> > Bus usb@fe38: USB EHCI 1.00
> > Bus usb@fe3a: USB OHCI 1.0
> > Bus usb@fe3c: USB EHCI 1.00
> > Bus usb@fe3e: USB OHCI 1.0
> > Bus dwc3: usb maximum-speed not found
> > Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb@fe38 for devices... 1 USB Device(s) found
> > scanning bus usb@fe3a for devices... 1 USB Device(s) found
> > scanning bus usb@fe3c for devices... 1 USB Device(s) found
> > scanning bus usb@fe3e for devices... 1 USB Device(s) found
> > scanning bus dwc3 for devices... 1 USB Device(s) found
> > scanning usb for storage devices... 0 Storage Device(s) found
> > => boot
> > Card did not respond to voltage select! : -110
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Found /extlinux/extlinux.conf
> > Retrieving file: /extlinux/extlinux.conf
> > 144 bytes read in 5 ms (27.3 KiB/s)
> > 1:  Debian-Installer
> > Retrieving file: /initrd.gz
> > 28995285 bytes read in 1287 ms (21.5 MiB/s)
> > Retrieving file: /vmlinuz
> > 26922864 bytes read in 1195 ms (21.5 MiB/s)
> > Retrieving file: /dtbs/rockchip/rk3399-rockpro64.dtb
> > 56849 bytes read in 13 ms (4.2 MiB/s)
> > Moving Image from 0x208 to 0x220, end=3c5
> > ## Flattened Device Tree blob at 01f0
> > Booting using the fdt blob at 0x1f0
> > 
> > 
> > 
> > live well,
> >vagrant
> 
> 
> 

Re: [PATCH] efi_loader: improve detection of ESP for storing UEFI variables

[Jonathan Gray]

On Sat, Nov 14, 2020 at 05:56:38AM +0100, Heinrich Schuchardt wrote:
> On 09.11.20 18:08, Mark Kettenis wrote:
> >> From: Heinrich Schuchardt 
> >> Date: Mon, 9 Nov 2020 15:36:33 +0100
> >>
> >> On 09.11.20 14:51, Mark Kettenis wrote:
>  From: Paulo Alcantara 
>  Date: Mon, 09 Nov 2020 10:24:08 -0300
> 
>  Heinrich Schuchardt  writes:
> 
> > On 09.11.20 00:58, Paulo Alcantara wrote:
> >> The UEFI specification does not restrict on the number and location of
> >> ESPs in a system.  They are discovered as required by looking at the
> >> partition type, but firmware implementations are allowed to support
> >> ESPs which do not contain a valid partition type.
> >
> > I guess you refer to chapter "13.3.3 Number and Location of System
> > Partitions" of the UEFI spec saying: "Further, UEFI implementations
> > may allow the use of conforming FAT partitions which do not use the
> > ESP GUID."
> 
>  Yep, sorry.  Thanks for pointing it out!
> 
> > Why should U-Boot support FAT partitions that are not of type FAT 0xef
> > and GPT partition that do not use the ESP GUID?
> 
>  In most UEFI (EDK2-based) systems I used, I could boot my OSes and
>  diagnostic tools by simply having a supported filesystem (FAT12/16/32)
>  and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
>  partition type at all.  It took me a while for figuring out why I
>  couldn't get my UEFI variables loaded from my FAT partition that
>  contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
> >>>
> >>> The OpenBSD installation media for armv7 and arm64 use a FAT partition
> >>> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
> >>> This allows us to have a single FAT partition with the Raspberry Pi
> >>> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
> >>>
> >>> So far this works on all UEFI firmware I've tried (EDK2, U-Boot and
> >>> AMI AptioV UEFI).
> >>>
> >>
> >> The issue Paulo was addressing is that U-Boot only persists non-volatile
> >> UEFI variables if it can find a partition indicated as ESP by the
> >> partition type.
> >>
> >> This becomes interesting if you want to have both Linux and OpenBSD on
> >> the same device and you want to use UEFI boot variables to decide which
> >> operating system to boot or if you want to use secure boot.
> >>
> >> On Debian the ESP is an 0xef partition mounted at /boot/efi.
> >>
> >> SUSE recommends the same:
> >> https://www.suse.com/support/kb/doc/?id=17007
> >> https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html
> >>
> >> For a Raspberry I typically would have the following partitions:
> >>
> >> / - root file system
> >> /boot/firmware - *first* FAT partition
> >> /boot/efi - ESP, FAT formatted
> >>
> >> As /boot/firmware and /boot/efi can be separate partitions with
> >> different partition type why does OpenBSD not use this scheme?
> >
> > Two reasons:
> >
> > 1. The installer and the scripts that build the installer image only
> >support creating a single FAT partition.
> >
> > 2. Adding another FAT partition would consume another slot in the
> >disklabel[1] which doesn't have a lot of empty slots left for a
> >default install.
> 
> OpenBSD itself uses just a single partition of type 0xa6 on the SD-Card.
> 
> U-Boot supports logical partitions. So you can have three primary
> partitions and additionally 60 logical partitions in your extended
> partition. So the number of available slots should be the least of your
> worries.

mbr, gpt, apple partion map, sgi disklabel etc are all mapped onto
an OpenBSD disklabel, one is spoofed if it doesn't exist.

https://man.openbsd.org/disklabel.5

"disklabel only supports up to a maximum of 15 partitions, ‘a’ through
‘p’, excluding ‘c’. The ‘c’ partition is reserved for the entire
physical disk. By convention, the ‘a’ partition of the boot disk is the
root partition, and the ‘b’ partition of the boot disk is the swap
partition, but all other letters can be used in any order for any other
partitions as desired."

What looks like a single mbr partition is normally used as multiple
disklabel partitions.  For swap /tmp /var etc.  Partitions outside the
OpenBSD area like FAT start showing up at 'i'.

Re: [PATCH] Fix MMC access on Sabrelite

[Jonathan Gray]

On Tue, May 26, 2020 at 06:02:23PM +0100, Martyn Welch wrote:
> It appears that MMC access on the Sabrelite has been broken since
> cdcaee9518:
> 
> Loading Environment from MMC... Card did not respond to voltage select!
> *** Warning - No block device, using default environment
> 
> Remove the board_mmc_init() and related entries now that we should be
> using DM_MMC, add PINCTRL so that things work as expected.

I had a report of this being broken in the OpenBSD package.
U-Boot built with this patch confirmed to fix it.

> 
> Signed-off-by: Martyn Welch 
> ---
>  board/boundary/nitrogen6x/nitrogen6x.c | 71 --
>  configs/mx6qsabrelite_defconfig|  3 ++
>  2 files changed, 3 insertions(+), 71 deletions(-)
> 
> diff --git a/board/boundary/nitrogen6x/nitrogen6x.c 
> b/board/boundary/nitrogen6x/nitrogen6x.c
> index d49725daa8..5eb810f4ad 100644
> --- a/board/boundary/nitrogen6x/nitrogen6x.c
> +++ b/board/boundary/nitrogen6x/nitrogen6x.c
> @@ -161,26 +161,6 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
>   IOMUX_PAD_CTRL(SD2_DAT3__SD2_DATA3, USDHC_PAD_CTRL),
>  };
>  
> -static iomux_v3_cfg_t const usdhc3_pads[] = {
> - IOMUX_PAD_CTRL(SD3_CLK__SD3_CLK, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_CMD__SD3_CMD, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT0__SD3_DATA0, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT1__SD3_DATA1, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT2__SD3_DATA2, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT3__SD3_DATA3, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT5__GPIO7_IO00, NO_PAD_CTRL), /* CD */
> -};
> -
> -static iomux_v3_cfg_t const usdhc4_pads[] = {
> - IOMUX_PAD_CTRL(SD4_CLK__SD4_CLK, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_CMD__SD4_CMD, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT0__SD4_DATA0, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT1__SD4_DATA1, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT2__SD4_DATA2, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT3__SD4_DATA3, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(NANDF_D6__GPIO2_IO06, NO_PAD_CTRL), /* CD */
> -};
> -
>  static iomux_v3_cfg_t const enet_pads1[] = {
>   IOMUX_PAD_CTRL(ENET_MDIO__ENET_MDIO, ENET_PAD_CTRL),
>   IOMUX_PAD_CTRL(ENET_MDC__ENET_MDC, ENET_PAD_CTRL),
> @@ -305,57 +285,6 @@ int board_ehci_power(int port, int on)
>  
>  #endif
>  
> -#ifdef CONFIG_FSL_ESDHC_IMX
> -static struct fsl_esdhc_cfg usdhc_cfg[2] = {
> - {USDHC3_BASE_ADDR},
> - {USDHC4_BASE_ADDR},
> -};
> -
> -int board_mmc_getcd(struct mmc *mmc)
> -{
> - struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
> - int gp_cd = (cfg->esdhc_base == USDHC3_BASE_ADDR) ? IMX_GPIO_NR(7, 0) :
> - IMX_GPIO_NR(2, 6);
> -
> - gpio_direction_input(gp_cd);
> - return !gpio_get_value(gp_cd);
> -}
> -
> -int board_mmc_init(bd_t *bis)
> -{
> - int ret;
> - u32 index = 0;
> -
> - usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
> - usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
> -
> - usdhc_cfg[0].max_bus_width = 4;
> - usdhc_cfg[1].max_bus_width = 4;
> -
> - for (index = 0; index < CONFIG_SYS_FSL_USDHC_NUM; ++index) {
> - switch (index) {
> - case 0:
> - SETUP_IOMUX_PADS(usdhc3_pads);
> - break;
> - case 1:
> -SETUP_IOMUX_PADS(usdhc4_pads);
> -break;
> - default:
> -printf("Warning: you configured more USDHC controllers"
> -"(%d) then supported by the board (%d)\n",
> -index + 1, CONFIG_SYS_FSL_USDHC_NUM);
> -return -EINVAL;
> - }
> -
> - ret = fsl_esdhc_initialize(bis, _cfg[index]);
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -#endif
> -
>  #ifdef CONFIG_MXC_SPI
>  int board_spi_cs_gpio(unsigned bus, unsigned cs)
>  {
> diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
> index ea338c1b53..39b0ef7a42 100644
> --- a/configs/mx6qsabrelite_defconfig
> +++ b/configs/mx6qsabrelite_defconfig
> @@ -28,6 +28,7 @@ CONFIG_CMD_GPT=y
>  # CONFIG_RANDOM_UUID is not set
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> +# CONFIG_CMD_PINMUX is not set
>  CONFIG_CMD_SATA=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_USB_MASS_STORAGE=y
> @@ -55,6 +56,8 @@ CONFIG_PHYLIB=y
>  CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_IMX6=y
>  CONFIG_SPI=y
>  CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
> -- 
> 2.26.2
> 
> 

Re: [PATCH 0/2] omap4: panda: convert to device model

[Jonathan Gray]

On Tue, Jun 02, 2020 at 02:19:07PM +0300, Tero Kristo wrote:
> Hi,
> 
> As there is looming death to OMAP4 Panda board u-boot support, I decided
> to take a shot and convert it to device model myself. With these patches
> it boots up fine, and there are no DM_SPL conversion complaints during
> compile time anymore. I think USB ethernet does not work anymore with
> this, but its better than dropping the support for the board completely.
> USB itself appears working, so it should be relatively easy for someone
> to fix the networking support if they need it.
> 
> -Tero

Thanks, OpenBSD still boots on PandaBoard ES with these changes.

USB Ethernet does not seem to work before your patches on 2020.04
"Net:   No ethernet found."

-U-Boot SPL 2020.04 (May 26 2020 - 09:37:17 -0600)
+U-Boot SPL 2020.07-rc3-00212-g83e9328144 (Jun 06 2020 - 17:18:39 +1000)
 OMAP4460-GP ES1.1
 Trying to boot from MMC1
-SPL: Please implement spl_start_uboot() for your board
-SPL: Direct Linux boot not active!
+spl_load_image_fat_os: error reading image args, err - -2
 
 
-U-Boot 2020.04 (May 26 2020 - 09:37:17 -0600)
+U-Boot 2020.07-rc3-00212-g83e9328144 (Jun 06 2020 - 17:18:39 +1000)
 
 CPU  : OMAP4460-GP ES1.1
+Model: TI OMAP4 PandaBoard
 Board: OMAP4 Panda
 I2C:   ready
 DRAM:  1 GiB
@@ -23,67 +23,58 @@ SD/MMC found on device 0
 switch to partitions #0, OK
 mmc0 is current device
 Scanning mmc 0:1...
-83524 bytes read in 6 ms (13.3 MiB/s)
+83524 bytes read in 32 ms (2.5 MiB/s)
 Found EFI removable media binary efi/boot/bootarm.efi
-Scanning disks on usb...
-Disk usb0 not ready
-Disk usb1 not ready
-Disk usb2 not ready
-Disk usb3 not ready
-Scanning disks on mmc...
+Scanning disk m...@0.blk...
 ** Unrecognized filesystem type **
-MMC Device 1 not found
-MMC Device 2 not found
-MMC Device 3 not found
-Found 3 disks
 BootOrder not defined
 EFI boot manager: Cannot load any image
-105448 bytes read in 11 ms (9.1 MiB/s)
+105448 bytes read in 45 ms (2.2 MiB/s)
 disks: sd0*
 >> OpenBSD/armv7 BOOTARM 1.15
 boot>
-booting sd0a:/bsd: 4689044+688008+252268+562848-[254389+120+324848+288747]=0x0
+booting sd0a:/bsd: 4695860+688940+255424+565064\[254202+120+324848+288747]=0x0
 
 OpenBSD/armv7 booting ...


U-Boot SPL 2020.07-rc3-00212-g83e9328144 (Jun 06 2020 - 17:18:39 +1000)
OMAP4460-GP ES1.1
Trying to boot from MMC1
spl_load_image_fat_os: error reading image args, err - -2


U-Boot 2020.07-rc3-00212-g83e9328144 (Jun 06 2020 - 17:18:39 +1000)

CPU  : OMAP4460-GP ES1.1
Model: TI OMAP4 PandaBoard
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Net:   No ethernet found.
Hit any key to stop autoboot:  0
## Error: "init_console" not defined
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
83524 bytes read in 32 ms (2.5 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disk m...@0.blk...
** Unrecognized filesystem type **
BootOrder not defined
EFI boot manager: Cannot load any image
105448 bytes read in 45 ms (2.2 MiB/s)
disks: sd0*
>> OpenBSD/armv7 BOOTARM 1.15
boot>
booting sd0a:/bsd: 4695860+688940+255424+565064\[254202+120+324848+288747]=0x0

OpenBSD/armv7 booting ...

Re: [PATCH] Azure: Add 'tools-only' build for macOS X hosts

[Jonathan Gray]

On Sat, May 16, 2020 at 02:54:39PM -0400, Tom Rini wrote:
> Add building the 'tools-only' target on macOS X 'Catalina'.  Hopefully
> this will catch changes to host tools that are incompatible on BSD style
> environments.
> 
> Signed-off-by: Tom Rini 
> 
> Note that at this time commit 3b4847cbee7c
> ("efi_loader: support building UEFI binaries on sandbox") is causing
> this to fail as non-GNU make does not support 'undefine' and there's not
> gmake nor do we need (seemingly) to use gmake otherwise.  If we must, we
> can look in to 'brew install gmake' I think but I'm trying to have this
> be a typical BSD build environment.

For building U-Boot (with around 70 targets) in OpenBSD ports we depend
on the following additional ports not in the base system:

devel/gmake
devel/bison
devel/dtc
devel/swig
textproc/gsed (with check-config.sh patched to use it over base sed)
lang/python (python3)

for aarch64 targets
devel/arm-none-eabi/gcc-linaro,aarch64
devel/py-elftools
sysutils/arm-trusted-firmware

for arm targets
devel/arm-none-eabi/gcc-linaro

The host/system compiler on most OpenBSD platforms is clang.

I would like to move to doing native builds when building on aarch64 and
armv7 platforms with the system clang.  I wonder how many of the
warnings in doc/README.clang still apply.

> ---
>  .azure-pipelines.yml | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index 5d9645451d47..09b79f4241f8 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -1,6 +1,7 @@
>  variables:
>windows_vm: vs2017-win2016
>ubuntu_vm: ubuntu-18.04
> +  macos_vm: macOS-10.15
>ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200403-27Apr2020
># Add '-u 0' options for Azure pipelines, otherwise we get "permission
># denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer",
> @@ -44,6 +45,17 @@ jobs:
># Tell MSYS2 not to ‘cd’ our startup directory to HOME
>CHERE_INVOKING: yes
>  
> +  - job: tools_only_macOS
> +displayName: 'Ensure host tools build for macOS X'
> +pool:
> +  vmImage: $(macos_vm)
> +steps:
> +  - script: |
> +  make tools-only_config tools-only NO_SDL=1 \
> +HOSTCFLAGS="-I/usr/local/opt/openssl@1.1/include" \
> +HOSTLDFLAGS="-L/usr/local/opt/openssl@1.1/lib" \
> +-j$(sysctl -n hw.logicalcpu)
> +
>- job: cppcheck
>  displayName: 'Static code analysis with cppcheck'
>  pool:
> -- 
> 2.17.1
> 
> 

[PATCH] rsa: don't use malloc.h in rsa-sign.c

[Jonathan Gray]

stdlib.h is the header for malloc since at least c89/c90.
There is no system malloc.h on OpenBSD and trying to use malloc.h here
falls back to the U-Boot malloc.h breaking the build of qemu_arm64.

Fixes: 336d4615f8 ("dm: core: Create a new header file for 'compat' features")
Signed-off-by: Jonathan Gray 
---
 lib/rsa/rsa-sign.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 580c744709..621ddc4350 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -4,7 +4,7 @@
  */
 
 #include "mkimage.h"
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.26.2

Re: Question about GPL v3 font

[Jonathan Gray]

On Sun, Jan 12, 2020 at 07:45:49PM +1300, Simon Glass wrote:
> Hi Wolfgang,
> 
> On Fri, 23 Aug 2019 at 21:51, Wolfgang Denk  wrote:
> >
> > Dear Tom,
> >
> > In message <20190726170700.GQ20116@bill-the-cat> you wrote:
> > >
> > > >   It was designed in 1987. A subset of Nimbus Sans L were 
> > > > released
> > > >   under the GPL. Although the characters are not exactly the 
> > > > same,
> > > >   Nimbus Sans L has metrics almost identical to Helvetica and 
> > > > Ari=
> > > al.
> > > >   (From Wikipedia, the free encyclopedia)
> > > >   From: https://fontlibrary.org/en/font/nimbus-sans-l
> > > >   License: GNU GPL v3
> > > >   http://www.gnu.org/copyleft/gpl.html
> > >
> > > It's a good question.  I suspect the answer is that we should drop that
> > > font as I don't know if you can combine "GPLv2 only" and "GPLv2 or
> > > later" with "GPLv3".
> >
> > Should we not first make sure the license is really GPLv3?
> >
> > At the moment the URL https://fontlibrary.org/en/font/nimbus-sans-l
> > does not work.  But there are other sources which suggest that this
> > font might actually be GPLv2 instead, see for example "Licensing" at
> > https://www.fontsquirrel.com/fonts/nimbus-sans-l
> >
> > Or see https://www.1001fonts.com/nimbus-sans-l-font.html
> 
> Yes I see that now. I am not actually sure of the license but it is
> certainly possible it could be GPLv2. Is there a way to find the
> authoritative source?
> 
> I will send a patch to replace this with roboto, which seems to be
> clearly licensed.

Roboto is licensed under Apache 2.0

https://www.gnu.org/licenses/license-list.en.html#apache2
"Please note that this license is not compatible with GPL version 2"

Re: [PATCH 33/33] video: Drop the Nimbus font

[Jonathan Gray]

On Sun, Jan 12, 2020 at 12:06:24PM -0700, Simon Glass wrote:
> There is some concern that this font may be GPLv3 rather than GPLv2. This
> is is not desirable in U-Boot. Replace it with Roboto which has an Apache
> license.
> 
> See discussion here:
> 
> https://www.mail-archive.com/u-boot@lists.denx.de/msg335913.html

> diff --git a/drivers/video/fonts/Kconfig b/drivers/video/fonts/Kconfig
> index c692fa9602..1b8b59311e 100644
> --- a/drivers/video/fonts/Kconfig
> +++ b/drivers/video/fonts/Kconfig
> @@ -4,19 +4,19 @@
>  
>  menu "TrueType Fonts"
>  
> -config CONSOLE_TRUETYPE_NIMBUS
> - bool "Nimbus Sans Regular"
> +config CONSOLE_TRUETYPE_ROBOTO
> + bool "Roboto Regular"
>   depends on CONSOLE_TRUETYPE
>   default y
>   help
> -   Nimbus Sans L is a version of Nimbus Sans using Adobe font sources.
> -   It was designed in 1987. A subset of Nimbus Sans L were released
> -   under the GPL. Although the characters are not exactly the same,
> -   Nimbus Sans L has metrics almost identical to Helvetica and Arial.
> -   (From Wikipedia, the free encyclopedia)
> -   From: https://fontlibrary.org/en/font/nimbus-sans-l
> -   License: GNU GPL v3
> -   http://www.gnu.org/copyleft/gpl.html
> +   Roboto was created in 2011 by Christian Robertson at Google, and
> +   received a significant redesign in 2014. It is a sans-serif grotesque,
> +   which is the same classification as Helvetica and Akzidenz-Grotesk.
> +   Roboto is the default font on the Android mobile phone operating
> +   system.
> +   From: https://fontlibrary.org/en/font/roboto
> +   License: Apache 2.0
> +   https://www.apache.org/licenses/LICENSE-2.0

https://www.gnu.org/licenses/license-list.en.html#apache2

"Please note that this license is not compatible with GPL version 2"

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Jonathan Gray]

On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
> Hi Vagrant,
> 
> On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  wrote:
> >
> > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
> > u-boot.img from MMC:
> >
> > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 -
> > 08:03:23 +)
> > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19
> > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices
> > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ###
> 
> Thanks for reporting this issue.
> 
> Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
> and Baruch on Cc.

Works after reverting the following commit.

14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit
commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a
Author: Adam Ford 
Date:   Thu May 23 14:11:30 2019 -0500

spl: imx6: Let spl_boot_device return USDHC1 or USDHC2

Currently, when the spl_boot_device checks the boot device, it
will only return MMC1 when it's either sd or eMMC regardless
of whether or not it's MMC1 or MMC2.  This is a problem when
booting from MMC2 if MMC isn't being manually configured like in
the DM_SPL case with SPL_OF_CONTROL.

This patch will check the register and return either MMC1 or MMC2.

Signed-off-by: Adam Ford 

 arch/arm/mach-imx/spl.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] am335x_evm SPL no longer fits

[Jonathan Gray]

On Tue, Sep 24, 2019 at 04:58:48PM +1000, Jonathan Gray wrote:
> As of v2019.10-rc3 am335x_evm builds fail here as SPL doesn't fit.
> 
> v2019.10-rc2 builds.
> v2019.10-rc4 still fails:
> 
>   LD  spl/u-boot-spl
> arm-none-eabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in 
> region `.sram'
> arm-none-eabi-ld.bfd: region `.sram' overflowed by 100 bytes
> 
> I bisected this to the below commit but reverting it only slightly helps
> 
> arm-none-eabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in 
> region `.sram'
> arm-none-eabi-ld.bfd: region `.sram' overflowed by 72 bytes
> 
> Building with gcc-linaro-6.3.2017.02 and binutils-2.27

fits with gcc-linaro-7.4.2019.02
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] am335x_evm SPL no longer fits

[Jonathan Gray]

As of v2019.10-rc3 am335x_evm builds fail here as SPL doesn't fit.

v2019.10-rc2 builds.
v2019.10-rc4 still fails:

  LD  spl/u-boot-spl
arm-none-eabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region 
`.sram'
arm-none-eabi-ld.bfd: region `.sram' overflowed by 100 bytes

I bisected this to the below commit but reverting it only slightly helps

arm-none-eabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region 
`.sram'
arm-none-eabi-ld.bfd: region `.sram' overflowed by 72 bytes

Building with gcc-linaro-6.3.2017.02 and binutils-2.27

b83edfbde9a845d47a2766f4677deb336abfa42a is the first bad commit
commit b83edfbde9a845d47a2766f4677deb336abfa42a
Author: Lukas Auer 
Date:   Wed Aug 21 21:14:42 2019 +0200

spl: fit: use U-Boot device tree when FIT image has no device tree

As part of the SPL FIT boot flow, the device tree is appended to U-Boot
proper. The device tree is used to record information on the loadables
to make them available to the SPL framework and U-Boot proper. Depending
on the U-Boot device tree provider, the FIT image might not include a
device tree. Information on the loadables is missing in this case.

When booting via firmware bundled with the FIT image, U-Boot SPL loads
the firmware binary and U-Boot proper before starting the firmware. The
firmware, in turn, is responsible for starting U-Boot proper.
Information on the memory location of the U-Boot proper loadable must be
available to the SPL framework so that it can be passed to the firmware
binary. To support this use case when no device tree is found in the FIT
image, fall back to the U-Boot device tree in this situation.

At the same time, update the comment to remove the note that the
destination address must be aligned to ARCH_DMA_MINALIGN. Alignment is
only required as an intermediate step when reading external data. This
is automatically handled by spl_fit_append_fdt(). After reading the
external data, it is copied to the specified address, which does not
have to be aligned to ARCH_DMA_MINALIGN.

Signed-off-by: Lukas Auer 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Reviewed-by: Anup Patel 

 common/spl/spl_fit.c | 37 -
 1 file changed, 24 insertions(+), 13 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】

[Jonathan Gray]

On Mon, Sep 23, 2019 at 01:55:32PM +, Alexander von Gluck IV wrote:
> Oh, a difference:
> 
> $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \
> cat spl/u-boot-spl-dtb.bin >> idbloader.img
> 
> I'm using the idbloader.img that u-boot automatically spits out.
> 
> $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader-manual.img
> Image Type:   Rockchip RK32 (SD/MMC) boot image
> Data Size:20480 bytes
> $ cat spl/u-boot-spl-dtb.bin >> idbloader-manual.img
> 
> However.. the generated idbloader-manual.img from the commands above is 
> identical to idbloader.img
> that u-boot produces compared with md5sum.
> 
> 
> Are you writing the following?
> 
>   sudo dd if=idbloader.img of=/dev/sdd seek=64
>   sudo dd if=u-boot-dtb.img of=/dev/sdd seek=16384

those files/offsets yes

> 
> (where /dev/sdd is a MicroSD card)
> 
> These should be enough to get into u-boot at startup... correct?

yes

I am using uart2
https://www.asus.com/us/Single-Board-Computer/Tinker-Board/
32 UART2TX_PWM3
33 UART2RX_PWM2
and 30 for ground

> 
> I'm not missing some requirement of u-boot.bin on a FAT32 partition or 
> something?

the tpl/spl and u-boot proper are at raw offsets in this case

> 
>  -- Alex
> 
> September 23, 2019 8:31 AM, "Jonathan Gray"  wrote:
> 
> > On Mon, Sep 23, 2019 at 01:06:35PM +, Alexander von Gluck IV wrote:
> > 
> >> Ok, looking for differences now..
> >> 
> >> * Older Tinker Board? (I'm not using the Tinker Board S)
> > 
> > yes, the original one
> > 
> >> * Same steps?
> > 
> > along the lines of
> > 
> > gmake CROSS_COMPILE="arm-none-eabi-" tinker-rk3288_defconfig
> > gmake CROSS_COMPILE="arm-none-eabi-" all
> > tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \
> > cat spl/u-boot-spl-dtb.bin >> idbloader.img
> > 
> >> * Same config? tinker-rk3288_defconfig?
> > 
> > yes
> > 
> >> * Uart 115200?
> > 
> > yes
> > 
> >> * Any HDMI Video output?
> > 
> > no hdmi connected only serial
> > 
> >> * GCC version?
> > 
> > gcc-linaro-6.3.2017.02 binutils 2.27 arm-none-eabi target
> > 
> >> September 23, 2019 12:34 AM, "Jonathan Gray"  wrote:
> >> 
> >> On Mon, Sep 23, 2019 at 01:17:40AM +, Alexander von Gluck IV wrote:
> >> 
> >> Hello!
> >> 
> >> There is no uart output and no video with u-boot master.
> >> The board works as expected booting the Asus Armbian image on an SD.
> >> 
> >> At this point i'd be happy to get some u-boot uart output :-)
> >> 
> >> -- Alex
> >> 
> >> uart output works here with the latest master
> >> (780a17e814503f71d1b51d578b32bc9c89933183)
> >> 
> >> U-Boot TPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20)
> >> Trying to boot from BOOTROM
> >> Returning to boot ROM...
> >> 
> >> U-Boot SPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000)
> >> Trying to boot from MMC1
> >> 
> >> U-Boot 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000)
> >> 
> >> Model: Tinker-RK3288
> >> DRAM: 2 GiB
> >> MMC: dwmmc@ff0c: 1
> >> Loading Environment from MMC... *** Warning - bad CRC, using default 
> >> environment
> >> 
> >> In: serial
> >> Out: serial
> >> Err: serial
> >> Model: Tinker-RK3288
> >> rockchip_dnl_key_pressed: adc_channel_single_shot fail!
> >> Net: eth0: ethernet@ff29
> >> Hit any key to stop autoboot: 0
> >> switch to partitions #0, OK
> >> mmc1 is current device
> >> Scanning mmc 1:1...
> >> Found EFI removable media binary efi/boot/bootarm.efi
> >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> >> Scanning disk dw...@ff0c.blk...
> >> Found 3 disks
> >> BootOrder not defined
> >> EFI boot manager: Cannot load any image
> >> 88176 bytes read in 9 ms (9.3 MiB/s)
> >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> >> OpenBSD/armv7 BOOTARM 1.6
> >> 
> >> boot>
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】

[Jonathan Gray]

On Mon, Sep 23, 2019 at 01:06:35PM +, Alexander von Gluck IV wrote:
> Ok, looking for differences now..
> 
> * Older Tinker Board?  (I'm not using the Tinker Board S)

yes, the original one

> * Same steps?

along the lines of

gmake CROSS_COMPILE="arm-none-eabi-" tinker-rk3288_defconfig
gmake CROSS_COMPILE="arm-none-eabi-" all
tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \
cat spl/u-boot-spl-dtb.bin >> idbloader.img

> * Same config?  tinker-rk3288_defconfig?

yes

> * Uart 115200?

yes

> * Any HDMI Video output?

no hdmi connected only serial

> * GCC version?

gcc-linaro-6.3.2017.02 binutils 2.27 arm-none-eabi target

> 
> September 23, 2019 12:34 AM, "Jonathan Gray"  wrote:
> 
> > On Mon, Sep 23, 2019 at 01:17:40AM +, Alexander von Gluck IV wrote:
> > 
> >> Hello!
> >> 
> >> There is no uart output and no video with u-boot master.
> >> The board works as expected booting the Asus Armbian image on an SD.
> >> 
> >> At this point i'd be happy to get some u-boot uart output :-)
> >> 
> >> -- Alex
> > 
> > uart output works here with the latest master
> > (780a17e814503f71d1b51d578b32bc9c89933183)
> > 
> > U-Boot TPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20)
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> > 
> > U-Boot SPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000)
> > Trying to boot from MMC1
> > 
> > U-Boot 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000)
> > 
> > Model: Tinker-RK3288
> > DRAM: 2 GiB
> > MMC: dwmmc@ff0c: 1
> > Loading Environment from MMC... *** Warning - bad CRC, using default 
> > environment
> > 
> > In: serial
> > Out: serial
> > Err: serial
> > Model: Tinker-RK3288
> > rockchip_dnl_key_pressed: adc_channel_single_shot fail!
> > Net: eth0: ethernet@ff29
> > Hit any key to stop autoboot: 0
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Found EFI removable media binary efi/boot/bootarm.efi
> > libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > Scanning disk dw...@ff0c.blk...
> > Found 3 disks
> > BootOrder not defined
> > EFI boot manager: Cannot load any image
> > 88176 bytes read in 9 ms (9.3 MiB/s)
> > libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> >>> OpenBSD/armv7 BOOTARM 1.6
> > 
> > boot>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】

[Jonathan Gray]

On Mon, Sep 23, 2019 at 01:17:40AM +, Alexander von Gluck IV wrote:
> Hello!
> 
> There is no uart output and no video with u-boot master.
> The board works as expected booting the Asus Armbian image on an SD.
> 
> At this point i'd be happy to get some u-boot uart output :-)
> 
>  -- Alex

uart output works here with the latest master
(780a17e814503f71d1b51d578b32bc9c89933183)

U-Boot TPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000)
Trying to boot from MMC1


U-Boot 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000)

Model: Tinker-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Model: Tinker-RK3288
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:   eth0: ethernet@ff29
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found EFI removable media binary efi/boot/bootarm.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk dw...@ff0c.blk...
Found 3 disks
BootOrder not defined
EFI boot manager: Cannot load any image
88176 bytes read in 9 ms (9.3 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> OpenBSD/armv7 BOOTARM 1.6
boot>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] config: enable DFU over USB on Raspberry Pi4 boards

[Jonathan Gray]

On Mon, Sep 16, 2019 at 02:53:30PM +0200, Marek Szyprowski wrote:
> Hi Matthias,
> 
> On 16.09.2019 14:45, Matthias Brugger wrote:
> > On 16/09/2019 14:24, Marek Szyprowski wrote:
> >> Enable support for DFU over USB. This requires to enable USB gadget,
> >> DWC2 UDC OTG driver and DFU command. DFU entities are defined for the
> >> following firmware objects: u-boot.bin, uboot.env and zImage.
> >>
> >> Signed-off-by: Marek Szyprowski 
> >> ---
> >>   configs/rpi_4_32b_defconfig | 11 +++
> >>   include/configs/rpi.h   | 10 ++
> >>   2 files changed, 21 insertions(+)
> >>
> >> diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
> >> index a31a617a5fb..0a375b97369 100644
> >> --- a/configs/rpi_4_32b_defconfig
> >> +++ b/configs/rpi_4_32b_defconfig
> >> @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y
> >>   # CONFIG_DISPLAY_CPUINFO is not set
> >>   # CONFIG_DISPLAY_BOARDINFO is not set
> >>   CONFIG_SYS_PROMPT="U-Boot> "
> >> +CONFIG_CMD_DFU=y
> >>   # CONFIG_CMD_FLASH is not set
> >>   CONFIG_CMD_GPIO=y
> >>   CONFIG_CMD_MMC=y
> >> @@ -19,6 +20,7 @@ CONFIG_CMD_FS_UUID=y
> >>   CONFIG_ENV_FAT_INTERFACE="mmc"
> >>   CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> >>   CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> >> +CONFIG_DFU_MMC=y
> >>   CONFIG_DM_KEYBOARD=y
> >>   CONFIG_DM_MMC=y
> >>   CONFIG_MMC_SDHCI=y
> >> @@ -26,6 +28,15 @@ CONFIG_MMC_SDHCI_BCM2835=y
> >>   CONFIG_PINCTRL=y
> >>   # CONFIG_PINCTRL_GENERIC is not set
> >>   # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
> >> +CONFIG_USB=y
> >> +CONFIG_DM_USB=y
> >> +CONFIG_DM_USB_GADGET=y
> >> +CONFIG_USB_GADGET=y
> >> +CONFIG_USB_GADGET_MANUFACTURER="FSL"
> >> +CONFIG_USB_GADGET_VENDOR_NUM=0x0525
> >> +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
> >> +CONFIG_USB_GADGET_DWC2_OTG=y
> >> +CONFIG_USB_GADGET_DOWNLOAD=y
> > Does this only work on RPi4? It seems to me that this should also be 
> > working on
> > the other RPi's. Do you have such HW to test?
> 
> It should work on any RPi with USB device controller available on the 
> micro-usb/c-usb connector. AFAIK, besides RPi4, only some RPi0 has USB 
> device mode available. Other RPi's have USB hub connected to DWC2 
> controller, so switching DWC2 to device mode is not enough to make it 
> working.
> 
> However I have access only to RPi3 and RPi4.

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/device.md

The following devices can boot using USB device boot mode:

Pi Compute Module
Pi Compute Module 3
Pi Zero
Pi Zero W
Pi A
Pi A+
Pi 3A+
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()

[Jonathan Gray]

On Fri, Jul 19, 2019 at 08:25:45PM +0200, Heinrich Schuchardt wrote:
> In GRUB before 2.04 a bug existed which did not allow booting some ARM32
> boards if U-Boot did not disable caches, cf.
> https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html
> 
> In ExitBootServices() we were disabling the caches by calling
> cleanup_before_linux(). This workaround is not needed anymore.

It is required for at least OpenBSD, FreeBSD and NetBSD.
Which are all now forced to carry patches to be able to use U-Boot.

> 
> The UEFI spec requires that caches are enabled but architecturally defined
> caches should be disabled. But this requirement has to be fulfilled when
> invoking StartImage() and not after calling ExitBootServices(). So there is
> no reason for calling cleanup_before_linux() here.
> 
> Since commit f69d63fae281 ("efi_loader: use efi_start_image() for
> bootefi"), i.e. v2019.04, we have not been calling efi_exit_caches()
> anymore which in turn would call cleanup_before_linux().
> 
> Remove the obsolete function efi_exit_caches().
> 
> Suggested-by: Alexander Graf 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 28 
>  1 file changed, 28 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 4f6e8d1679..f84ee24416 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -39,14 +39,6 @@ LIST_HEAD(efi_register_notify_events);
>  /* Handle of the currently executing image */
>  static efi_handle_t current_image;
> 
> -/*
> - * If we're running on nasty systems (32bit ARM booting into non-EFI Linux)
> - * we need to do trickery with caches. Since we don't want to break the EFI
> - * aware boot path, only apply hacks when loading exiting directly (breaking
> - * direct Linux EFI booting along the way - oh well).
> - */
> -static bool efi_is_direct_boot = true;
> -
>  #ifdef CONFIG_ARM
>  /*
>   * The "gd" pointer lives in a register on ARM and AArch64 that we declare
> @@ -1906,21 +1898,6 @@ error:
>   return EFI_EXIT(ret);
>  }
> 
> -/**
> - * efi_exit_caches() - fix up caches for EFI payloads if necessary
> - */
> -static void efi_exit_caches(void)
> -{
> -#if defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
> - /*
> -  * Grub on 32bit ARM needs to have caches disabled before jumping into
> -  * a zImage, but does not know of all cache layers. Give it a hand.
> -  */
> - if (efi_is_direct_boot)
> - cleanup_before_linux();
> -#endif
> -}
> -
>  /**
>   * efi_exit_boot_services() - stop all boot services
>   * @image_handle: handle of the loaded image
> @@ -1990,9 +1967,6 @@ static efi_status_t EFIAPI 
> efi_exit_boot_services(efi_handle_t image_handle,
>   /* Patch out unsupported runtime function */
>   efi_runtime_detach();
> 
> - /* Fix up caches for EFI payloads if necessary */
> - efi_exit_caches();
> -
>   /* This stops all lingering devices */
>   bootm_disable_interrupts();
> 
> @@ -2893,8 +2867,6 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
> image_handle,
>   if (ret != EFI_SUCCESS)
>   return EFI_EXIT(EFI_INVALID_PARAMETER);
> 
> - efi_is_direct_boot = false;
> -
>   image_obj->exit_data_size = exit_data_size;
>   image_obj->exit_data = exit_data;
> 
> --
> 2.20.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] efi_loader: use efi_start_image() for bootefi

[Jonathan Gray]

On Fri, Jul 19, 2019 at 07:43:17AM +0200, Heinrich Schuchardt wrote:
> On 7/19/19 1:07 AM, Mark Kettenis wrote:
> > > From: Alexander Graf 
> > > Date: Thu, 18 Jul 2019 20:50:39 +0200
> > > 
> > > On 18.07.19 19:33, Heinrich Schuchardt wrote:
> > > > On 7/18/19 11:16 AM, Jonathan Gray wrote:
> > > > > On Thu, Jul 18, 2019 at 10:39:57AM +0200, Mark Kettenis wrote:
> > > > > > > Date: Thu, 18 Jul 2019 16:00:16 +1000
> > > > > > > From: Jonathan Gray 
> > > > > > > 
> > > > > > > On Fri, Feb 08, 2019 at 07:46:49PM +0100, Heinrich Schuchardt 
> > > > > > > wrote:
> > > > > > > > Remove the duplicate code in efi_do_enter() and use
> > > > > > > > efi_start_image() to
> > > > > > > > start the image invoked by the bootefi command.
> > > > > > > > 
> > > > > > > > Signed-off-by: Heinrich Schuchardt 
> > > > > > > > ---
> > > > > > > > v2
> > > > > > > >  use EFI_CALL
> > > > > > > 
> > > > > > > This commit broke booting OpenBSD/armv7 kernels on mx6cuboxi with
> > > > > > > U-Boot
> > > > > > > releases after 2019.01.?? 2019.04 works if this commit is 
> > > > > > > reverted.
> > > > > > > With
> > > > > > > 2019.07 there are conflicts trying to revert it and it is still 
> > > > > > > broken
> > > > > > > as released.
> > > > > > > 
> > > > > > > f69d63fae281ba98c3d063097cf4e95d17f3754d is the first bad commit
> > > > > > > commit f69d63fae281ba98c3d063097cf4e95d17f3754d
> > > > > > > Author: Heinrich Schuchardt 
> > > > > > > Date: Wed Dec 26 13:28:09 2018 +0100
> > > > > > > 
> > > > > > >   efi_loader: use efi_start_image() for bootefi
> > > > > > > 
> > > > > > >   Remove the duplicate code in efi_do_enter() and use
> > > > > > > efi_start_image() to
> > > > > > >   start the image invoked by the bootefi command.
> > > > > > > 
> > > > > > >   Signed-off-by: Heinrich Schuchardt 
> > > > > > > 
> > > > > > >  ?? cmd/bootefi.c | 22 
> > > > > > > +-
> > > > > > >  ?? include/efi_loader.h?? |?? 4 
> > > > > > >  ?? lib/efi_loader/efi_boottime.c |?? 6 +++---
> > > > > > >  ?? 3 files changed, 8 insertions(+), 24 deletions(-)
> > > > > > 
> > > > > > Hi Jonathan,
> > > > > > 
> > > > > > With this commit the OpenBSD bootloader (an EFI application) still
> > > > > > boots, but the loaded OpenBSD kernel doesn't isn't it?
> > > > > 
> > > > > Yes, when it fails the last thing on serial is:
> > > > > 
> > > > > ## Starting EFI application at 1200 ...
> > > > > > > OpenBSD/armv7 BOOTARM 1.3
> > > > > boot>
> > > > > booting sd0a:/bsd: 4572484+689312+238360+561608
> > > > > [298268+120+314400+278666]=0x0
> > > > > 
> > > > > > 
> > > > > > I bet the problem here is that efi_start_image() sets
> > > > > > efi_is_direct_boot to false, which means that efi_exit_caches() 
> > > > > > which
> > > > > > runs as a result of calling ExitBootServices() no longer
> > > > > > flushes/disables the caches on 32-bit ARM.
> > > > > 
> > > > > Indeed, removing 'efi_is_direct_boot = false;' from
> > > > > efi_start_image() allows me to boot multiuser on cubox with 2019.07.
> > > 
> > > 
> > > Heinrich asked me to clarify again in the mail thread.
> > > 
> > > The UEFI spec says that caches on 32bit ARM are supposed to be *enabled*
> > > always. That means throughout boot time, as well as after
> > > ExitBootServices(). So the behavior with efi_is_direct_boot = false is
> > > the expected behavior according to the spec.
> > > 
> > > The reason we have the hack above in the tree is that grub had a nasty
> > > 

Re: [U-Boot] [PATCH v2 3/4] efi_loader: use efi_start_image() for bootefi

[Jonathan Gray]

On Thu, Jul 18, 2019 at 10:39:57AM +0200, Mark Kettenis wrote:
> > Date: Thu, 18 Jul 2019 16:00:16 +1000
> > From: Jonathan Gray 
> > 
> > On Fri, Feb 08, 2019 at 07:46:49PM +0100, Heinrich Schuchardt wrote:
> > > Remove the duplicate code in efi_do_enter() and use efi_start_image() to
> > > start the image invoked by the bootefi command.
> > > 
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > > v2
> > >   use EFI_CALL
> > 
> > This commit broke booting OpenBSD/armv7 kernels on mx6cuboxi with U-Boot
> > releases after 2019.01.  2019.04 works if this commit is reverted.  With
> > 2019.07 there are conflicts trying to revert it and it is still broken
> > as released.
> > 
> > f69d63fae281ba98c3d063097cf4e95d17f3754d is the first bad commit
> > commit f69d63fae281ba98c3d063097cf4e95d17f3754d
> > Author: Heinrich Schuchardt 
> > Date:   Wed Dec 26 13:28:09 2018 +0100
> > 
> > efi_loader: use efi_start_image() for bootefi
> > 
> > Remove the duplicate code in efi_do_enter() and use efi_start_image() to
> > start the image invoked by the bootefi command.
> > 
> > Signed-off-by: Heinrich Schuchardt 
> > 
> >  cmd/bootefi.c | 22 +-
> >  include/efi_loader.h  |  4 
> >  lib/efi_loader/efi_boottime.c |  6 +++---
> >  3 files changed, 8 insertions(+), 24 deletions(-)
> 
> Hi Jonathan,
> 
> With this commit the OpenBSD bootloader (an EFI application) still
> boots, but the loaded OpenBSD kernel doesn't isn't it?

Yes, when it fails the last thing on serial is:

## Starting EFI application at 1200 ...
>> OpenBSD/armv7 BOOTARM 1.3
boot> 
booting sd0a:/bsd: 4572484+689312+238360+561608 [298268+120+314400+278666]=0x0

> 
> I bet the problem here is that efi_start_image() sets
> efi_is_direct_boot to false, which means that efi_exit_caches() which
> runs as a result of calling ExitBootServices() no longer
> flushes/disables the caches on 32-bit ARM.

Indeed, removing 'efi_is_direct_boot = false;' from
efi_start_image() allows me to boot multiuser on cubox with 2019.07.

> 
> We have been here before.  It really isn't possible to flush/disable
> the L2 cache on most 32-bit ARM implementations without SoC-specific
> code.  And having such code in the early kernel bootstrap code isn't
> really possible.
> 
> The comments in the code suggest that loading an EFI Linux kernel
> directly from U-Boot somehow works without flushing the caches.  But I
> don't understand how.  But I'm pretty sure this change break booting
> non-EFI Linux kernels through grub on 32-bit ARM platforms as well.
> 
> The UEFI spec has the following text (UEFI 2.5 section 2.3.5 "AArch32
> Platforms"):
> 
>   Implementations of boot services will enable architecturally
>   manageable caches and TLBs i.e., those that can be managed directly
>   using CP15 operations using mechanisms and procedures defined in the
>   ARM Architecture Reference Manual. They should not enable caches
>   requiring platform information to manage or invoke non-architectural
>   cache/TLB lockdown mechanisms
> 
> This suggests that the real problem here is that U-Boot enables the L2
> cache on i.MX6 which violates the spec.  But things will probably run
> notably slower without the L2 cache enabled.  Maybe the answer is to
> just flush/disable the L2 cache when ExitBootServices() is called?
> 
> 
> > > ---
> > >  cmd/bootefi.c | 22 +-
> > >  include/efi_loader.h  |  4 
> > >  lib/efi_loader/efi_boottime.c |  6 +++---
> > >  3 files changed, 8 insertions(+), 24 deletions(-)
> > > 
> > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > > index 7f9913c0ee..a2d38256e9 100644
> > > --- a/cmd/bootefi.c
> > > +++ b/cmd/bootefi.c
> > > @@ -133,20 +133,6 @@ done:
> > >   return ret;
> > >  }
> > >  
> > > -static efi_status_t efi_do_enter(
> > > - efi_handle_t image_handle, struct efi_system_table *st,
> > > - EFIAPI efi_status_t (*entry)(
> > > - efi_handle_t image_handle,
> > > - struct efi_system_table *st))
> > > -{
> > > - efi_status_t ret = EFI_LOAD_ERROR;
> > > -
> > > - if (entry)
> > > - ret = entry(image_handle, st);
> > > - st->boottime->exit(image_handle, ret, 0, NULL);
> > > - return ret;
> > > -}
> > > -
> > >  /*
> > >   * efi_carve_out_dt_rs

Re: [U-Boot] [PATCH v2 3/4] efi_loader: use efi_start_image() for bootefi

[Jonathan Gray]

On Fri, Feb 08, 2019 at 07:46:49PM +0100, Heinrich Schuchardt wrote:
> Remove the duplicate code in efi_do_enter() and use efi_start_image() to
> start the image invoked by the bootefi command.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2
>   use EFI_CALL

This commit broke booting OpenBSD/armv7 kernels on mx6cuboxi with U-Boot
releases after 2019.01.  2019.04 works if this commit is reverted.  With
2019.07 there are conflicts trying to revert it and it is still broken
as released.

f69d63fae281ba98c3d063097cf4e95d17f3754d is the first bad commit
commit f69d63fae281ba98c3d063097cf4e95d17f3754d
Author: Heinrich Schuchardt 
Date:   Wed Dec 26 13:28:09 2018 +0100

efi_loader: use efi_start_image() for bootefi

Remove the duplicate code in efi_do_enter() and use efi_start_image() to
start the image invoked by the bootefi command.

Signed-off-by: Heinrich Schuchardt 

 cmd/bootefi.c | 22 +-
 include/efi_loader.h  |  4 
 lib/efi_loader/efi_boottime.c |  6 +++---
 3 files changed, 8 insertions(+), 24 deletions(-)

> ---
>  cmd/bootefi.c | 22 +-
>  include/efi_loader.h  |  4 
>  lib/efi_loader/efi_boottime.c |  6 +++---
>  3 files changed, 8 insertions(+), 24 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 7f9913c0ee..a2d38256e9 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -133,20 +133,6 @@ done:
>   return ret;
>  }
>  
> -static efi_status_t efi_do_enter(
> - efi_handle_t image_handle, struct efi_system_table *st,
> - EFIAPI efi_status_t (*entry)(
> - efi_handle_t image_handle,
> - struct efi_system_table *st))
> -{
> - efi_status_t ret = EFI_LOAD_ERROR;
> -
> - if (entry)
> - ret = entry(image_handle, st);
> - st->boottime->exit(image_handle, ret, 0, NULL);
> - return ret;
> -}
> -
>  /*
>   * efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
>   *
> @@ -315,13 +301,7 @@ static efi_status_t do_bootefi_exec(void *efi,
>  
>   /* Call our payload! */
>   debug("%s: Jumping to 0x%p\n", __func__, image_obj->entry);
> -
> - if (setjmp(_obj->exit_jmp)) {
> - ret = image_obj->exit_status;
> - goto err_prepare;
> - }
> -
> - ret = efi_do_enter(_obj->header, , image_obj->entry);
> + ret = EFI_CALL(efi_start_image(_obj->header, NULL, NULL));
>  
>  err_prepare:
>   /* image has returned, loaded-image obj goes *poof*: */
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 3ce43f7a6f..512880ab8f 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -320,6 +320,10 @@ efi_status_t efi_create_handle(efi_handle_t *handle);
>  void efi_delete_handle(efi_handle_t obj);
>  /* Call this to validate a handle and find the EFI object for it */
>  struct efi_object *efi_search_obj(const efi_handle_t handle);
> +/* Start image */
> +efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle,
> + efi_uintn_t *exit_data_size,
> + u16 **exit_data);
>  /* Find a protocol on a handle */
>  efi_status_t efi_search_protocol(const efi_handle_t handle,
>const efi_guid_t *protocol_guid,
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 7a61a905f4..6c4e2f82ba 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1770,9 +1770,9 @@ error:
>   *
>   * Return: status code
>   */
> -static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle,
> -efi_uintn_t *exit_data_size,
> -u16 **exit_data)
> +efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle,
> + efi_uintn_t *exit_data_size,
> + u16 **exit_data)
>  {
>   struct efi_loaded_image_obj *image_obj =
>   (struct efi_loaded_image_obj *)image_handle;
> -- 
> 2.20.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Bring tinker-rk3288 back into SPL size limit?????????????????????????u-boot-boun...@lists.denx.de?????????

[Jonathan Gray]

On Tue, Jun 25, 2019 at 06:09:32PM +0800, Kever Yang wrote:
> Hi Tom,
> 
> I got a Tinker board today and try to boot with SD card to enable TPL.
> 
> The SPL for Tinker board is broken and the size is too big at v2019.04,
> and v2019.01 is OK.
> 
> Other than size limit, seems there are some other issue for Tinker board
> TPL,
> 
> I can't get any debug message from uart even after I enable TPL(works
> correctly)
> 
> and move the SPL to DDR without size limit, very strange, I need
> 
> more time to debug the SPL issue.

for the SPL size issue try master, it contains the following:

commit 68b90e57bc034e237923b02acb633dc4e91d44cb
Author: Heinrich Schuchardt 
AuthorDate: Wed Feb 27 20:05:43 2019 +0100
Commit: Tom Rini 
CommitDate: Tue Jun 11 08:13:05 2019 -0400

configs: tinker-rk3288 disable CONFIG_SPL_I2C_SUPPORT

The SPL for the Tinker Board has to fit into 32 KiB. Currently this limit
is exceeded.

CONFIG_SPL_I2C_SUPPORT is not needed to move to main U-Boot. So let's
disable it.

Suggested-by: David Wu 
Signed-off-by: Heinrich Schuchardt 
Reviewed-by: David Wu 
Reviewed-by: Philipp Tomsich 

diff --git a/configs/tinker-rk3288_defconfig b/configs/tinker-rk3288_defconfig
index 4b48689ee8..0e8cf73fe9 100644
--- a/configs/tinker-rk3288_defconfig
+++ b/configs/tinker-rk3288_defconfig
@@ -20,7 +20,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_TEXT_BASE=0xff704000
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
-CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y

> 
> 
> Thanks,
> - Kever
> On 06/18/2019 03:40 PM, Kever Yang wrote:
> >
> > On 06/10/2019 09:36 PM, Jagan Teki wrote:
> >> On Sat, Jun 8, 2019 at 11:35 PM Tom Rini  wrote:
> >>> Hey,
> >>>
> >>> With Heinrich's series to enforce a size limit on SPL and Simon
> >>> Goldschmidt's enhancements on top of that, we're now seeing that
> >>> tinker-rk3288 has an SPL that is too large to function.  And it's now
> >>> also causing the build to fail.  So, good that we're catching this at
> >>> least.  Can you please look into what we need to do to get the image to
> >>> fit within the size constraints?  Thanks!
> >> I have used TPL before with tinker while supporting falcon. I think we
> >> can use TPL here, what do you think?
> >>
> > Yes, enable TPL is a solution for this issue.
> > Since we are not able to control the SPL size easily on upstream, and
> > most rockchip SoCs have size limit for SRAM, so other than Tinker board,
> > there should be many other rk3288 based boards have the similar issue.
> >
> > Thanks,
> > - Kever
> >
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] pull request: raspberry pi updates

[Jonathan Gray]

On Mon, Jun 24, 2019 at 02:11:43PM -0400, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
> > On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
> > > On 6/12/19 10:08 PM, Tom Rini wrote:
> > > >On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> > > >>On 6/12/19 9:56 PM, Tom Rini wrote:
> > > >>>On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> > > Hi Matthias,
> > > 
> > > Have these been out on the list for general review? I don't remember
> > > seeing them.
> > > 
> > > On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger  
> > > wrote:
> > > >
> > > >Hi Tom,
> > > >
> > > >Please have a look on the following patches.
> > > >
> > > >Regards,
> > > >Matthias
> > > >
> > > >---
> > > >The following changes since commit 
> > > >fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> > > >
> > > >   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> > > >
> > > >are available in the Git repository at:
> > > >
> > > >   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> > > >
> > > >for you to fetch changes up to 
> > > >38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> > > >
> > > >   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER 
> > > > (2019-06-12 12:23:46
> > > >+0200)
> > > >
> > > >
> > > >- fix complation error for CONFIG_USB
> > > >- update RPi3 DTBs to v5.1-rc6 state
> > > >- add defconfig for RPi3 B+
> > > 
> > > Why do we need a separate config when it's detected and works
> > > perfectly well with the standard rpi_3 and rpi_3_32b configs?
> > > >>>
> > > >>>Good question.  It came from Heinrich, so Heinrich?
> > > >>
> > > >>If we call the bootefi command without a OS supplied device tree the
> > > >>U-Boot device tree is passed to the operating system.
> > > >>
> > > >>So we need a device tree which is a complete description of the
> > > >>respective system.
> > > >>
> > > >>On the Linaro boot-architecture list there has been a lengthy discussion
> > > >>with Linaro people thinking that it is the responsibility of the
> > > >>hardware and firmware to provide the correct device tree and not of the 
> > > >>OS.
> > > >
> > > >OK, but on Pi aren't we passed, and pass along, the dtb from the
> > > >previous stage?
> > > >
> > > Currently `bootefi` uses as default what it finds in $fdt_control_addr
> > > and provides this to GRUB, Linux, or any other payload.
> > 
> > Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
> > in a device tree, that U-Boot then uses?
> 
> I haven't taken this as I haven't gotten an answer to this part.  I
> could have sworn that the proprietary loader passed along the device
> tree that's passed by us to the next stage.

The firmware includes device trees

https://github.com/raspberrypi/firmware/tree/master/boot

At least OpenSUSE, OpenBSD and Fedora change the rpi defconfigs to
better use it:

https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/rpi-Enable-using-the-DT-provided-by-the-Raspberry-Pi.patch
https://github.com/openSUSE/u-boot/commit/121d9d775c6af6ba5d1c3f198f478404a9196f84.patch

From 121d9d775c6af6ba5d1c3f198f478404a9196f84 Mon Sep 17 00:00:00 2001
From: Alexander Graf 
Date: Wed, 21 Feb 2018 17:41:13 +0100
Subject: [PATCH] rpi: Use firmware provided device tree

Currently the firmware generates a device tree for us that we could
just use to adjust ourselves. We then on boot throw that away and
use our own built-in device tree to configure device access.

This is bad for a multitude of reasons. For starters, it breaks
overlay support in config.txt, confusing users. Much worse however
is that we are stuck with individual U-Boot builds per board.
The firmware can easily give us the right DT depending on the
target board and revision though.

So let's use the firmware provided device tree instead. That way
U-Boot as well as payloads loaded by it can automatically adapt
to variants of RPi hardware.

Signed-off-by: Alexander Graf 
Signed-off-by: Guillaume Gardet 
---
 configs/rpi_0_w_defconfig   | 2 +-
 configs/rpi_2_defconfig | 2 +-
 configs/rpi_3_32b_defconfig | 2 +-
 configs/rpi_3_defconfig | 2 +-
 configs/rpi_defconfig   | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 1ab35f1b253..d26010efac1 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_FS_UUID=y
-CONFIG_OF_EMBED=y
+CONFIG_OF_BOARD=y
 CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w"
 CONFIG_ENV_FAT_INTERFACE="mmc"
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index 53aa554cc74..2b6bbf1b4b4 100644
--- a/configs/rpi_2_defconfig
+++ 

Re: [U-Boot] rk3288 SPL size

[Jonathan Gray]

On Tue, Apr 16, 2019 at 04:49:12PM +1000, Jonathan Gray wrote:
> On Fri, Apr 05, 2019 at 12:10:21PM +0200, Wadim Egorov wrote:
> > Hi,
> > 
> > it seems the new common rockchip pinctrl driver does not really fit into
> > our phycore-rk3288 SPL setup. It works for every other rk3288 based
> > board because they don't need special power configurations at the SPL stage.
> 
> It turns out tinker-rk3288 SPL no longer fits in 2019.04 and previously
> worked fine in 2019.01.
> 
> Warning: SPL image is too large (size 0x8800) and will not boot
> Error: image verification failed
> 
> built with gcc-linaro 6.3.2017.02
> 
> bisecting led to the pinctrl changes.
> 
> with SPL_PINCTRL_ROCKCHIP disabled it fits and U-Boot output on
> serial gets as far as the efi loader then no output appears on serial
> when a kernel is loaded.

Changing the defconfig to not have CONFIG_SPL_I2C_SUPPORT=y also fits
and also still hangs on loading a kernel.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rk3288 SPL size

[Jonathan Gray]

On Fri, Apr 05, 2019 at 12:10:21PM +0200, Wadim Egorov wrote:
> Hi,
> 
> it seems the new common rockchip pinctrl driver does not really fit into
> our phycore-rk3288 SPL setup. It works for every other rk3288 based
> board because they don't need special power configurations at the SPL stage.

It turns out tinker-rk3288 SPL no longer fits in 2019.04 and previously
worked fine in 2019.01.

Warning: SPL image is too large (size 0x8800) and will not boot
Error: image verification failed

built with gcc-linaro 6.3.2017.02

bisecting led to the pinctrl changes.

with SPL_PINCTRL_ROCKCHIP disabled it fits and U-Boot output on
serial gets as far as the efi loader then no output appears on serial
when a kernel is loaded.

> 
> So my question is: is there any work going on to reduce the SPL size
> even more?
> 
> Besides that, I think I can remove the power stuff at the SPL stage from
> our board. The SOM was redesigned and is equipped with an STM8 connected
> to the RK818. The required setup we did before in the SPL is now done by
> the ST controller. I know there are only a few SOMs without the STM8 out
> in the wild. So if I remove it it will affect only a few people who
> probably already have both boards.
> 
> Regards,
> Wadim
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/1] efi_loader: Patch non-runtime code out at ExitBootServices already

[Jonathan Gray]

On Mon, Mar 11, 2019 at 12:44:24PM +0100, Heinrich Schuchardt wrote:
> On 3/11/19 9:03 AM, Ard Biesheuvel wrote:
> > On Mon, 11 Mar 2019 at 01:16, Heinrich Schuchardt  
> > wrote:
> >>
> >> From: Alexander Graf 
> >>
> >> While discussing something compeltely different, Ard pointed out
> >> that it might be legal to omit calling SetVirtualAddressMap altogether.
> >>
> >> There is even a patch on the Linux Kernel Mailing List that implements
> >> such behavior by now:
> >>
> >>   https://patchwork.kernel.org/patch/10782393/
> >>
> >> While that sounds great, we currently rely on the SetVirtualAddressMap
> >> call to remove all references to code that would not work outside of
> >> boot services.
> >>
> >> So let's patch out those bits already on the call to ExitBootServices,
> >> so that we can successfully run even when an OS chooses to omit
> >> any call to SetVirtualAddressMap.
> >>
> >> Reported-by: Ard Biesheuvel 
> >> Signed-off-by: Alexander Graf 
> >>
> >> OpenBSD is not calling SetVirtualAddressMap on ARM 32 bit.
> >>
> > 
> > I take it this means that OpenBSD does not support runtime services at
> > all on 32-bit ARM?
> 
> References to runtime services exist, e.g.:
> 
> sys/arch/armv7/stand/efiboot/efiboot.c:666:
> EFI_CALL(RS->ResetSystem, EfiResetShutdown, EFI_SUCCESS, 0, NULL);
> 
> But from what I see at first glance it seems to be for the interactive
> console before booting the kernel.

Runtime services are used on OpenBSD/arm64 to be able to access the
rtc on amd seattle machines.  Not currently used by the kernel on any
other platform (including amd64).

> 
> Best regards
> 
> Heinrich
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] rpi: add Compute Module 3+

[Jonathan Gray]

Add Raspberry Pi Compute Module 3+ to list of models, the revision code
is 0x10 according to the list on raspberrypi.org.

v2: Use the same dtb name as CM3 as CM3+ is a drop in replacement
for CM3.

Signed-off-by: Jonathan Gray 
---
 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 153a1fdcb7..617c892dde 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
false,
},
+   [0x10] = {
+   "Compute Module 3+",
+   DTB_DIR "bcm2837-rpi-cm3.dtb",
+   false,
+   },
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rpi: add Compute Module 3+

[Jonathan Gray]

On Wed, Jan 30, 2019 at 10:56:37PM +0100, Alexander Graf wrote:
> 
> 
> > Am 30.01.2019 um 22:38 schrieb Jonathan Gray :
> > 
> >> On Wed, Jan 30, 2019 at 04:13:44PM +0100, Alexander Graf wrote:
> >> Hi Jonathan,
> >> 
> >>> On 30.01.19 15:17, Jonathan Gray wrote:
> >>> Add Raspberry Pi Compute Module 3+ to list of models, the revision code
> >>> is 0x10 according to the list on raspberrypi.org.
> >>> 
> >>> Signed-off-by: Jonathan Gray 
> >>> ---
> >>> board/raspberrypi/rpi/rpi.c | 5 +
> >>> 1 file changed, 5 insertions(+)
> >>> 
> >>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> >>> index 153a1fdcb7..c118250740 100644
> >>> --- a/board/raspberrypi/rpi/rpi.c
> >>> +++ b/board/raspberrypi/rpi/rpi.c
> >>> @@ -143,6 +143,11 @@ static const struct rpi_model 
> >>> rpi_models_new_scheme[] = {
> >>>DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
> >>>false,
> >>>},
> >>> +[0x10] = {
> >>> +"Compute Module 3+",
> >>> +DTB_DIR "bcm2837-rpi-cm3-plus.dtb",
> >> 
> >> Is the dtb name already committed to? I haven't seen patches on the rpi
> >> kernel ML.
> > 
> > I didn't see an existing name in various linux trees.
> > 
> > There is currently no new dtb provided with the firmware either, though
> > https://raw.githubusercontent.com/raspberrypi/documentation/master/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf
> > states
> > 
> > "CM3+ modules require a software/firmware image dated November 2018 or
> > newer to function correctly."
> > 
> > So the firmware likely patches bcm2710-rpi-cm3.dtb before passing it on.
> 
> Or maybe it's identical to the CM3? It's supposed to be a drop in replacement 
> after all - and the other differences (wifi chip, usb hub) of the 3+ should 
> not apply to a CM.
> 
> So I guess either you send a patch to Linux that adds the cm3plus and only 
> changes the compatible/model properties over cm3 or we make the dtb name in 
> this patch the cm3 one.
> 
> Alex

Ok, I'll send a v2 with "bcm2837-rpi-cm3.dtb".
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rpi: add Compute Module 3+

[Jonathan Gray]

On Wed, Jan 30, 2019 at 04:13:44PM +0100, Alexander Graf wrote:
> Hi Jonathan,
> 
> On 30.01.19 15:17, Jonathan Gray wrote:
> > Add Raspberry Pi Compute Module 3+ to list of models, the revision code
> > is 0x10 according to the list on raspberrypi.org.
> > 
> > Signed-off-by: Jonathan Gray 
> > ---
> >  board/raspberrypi/rpi/rpi.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> > index 153a1fdcb7..c118250740 100644
> > --- a/board/raspberrypi/rpi/rpi.c
> > +++ b/board/raspberrypi/rpi/rpi.c
> > @@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] 
> > = {
> > DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
> > false,
> > },
> > +   [0x10] = {
> > +   "Compute Module 3+",
> > +   DTB_DIR "bcm2837-rpi-cm3-plus.dtb",
> 
> Is the dtb name already committed to? I haven't seen patches on the rpi
> kernel ML.

I didn't see an existing name in various linux trees.

There is currently no new dtb provided with the firmware either, though
https://raw.githubusercontent.com/raspberrypi/documentation/master/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf
states

"CM3+ modules require a software/firmware image dated November 2018 or
newer to function correctly."

So the firmware likely patches bcm2710-rpi-cm3.dtb before passing it on.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rpi: add Compute Module 3+

[Jonathan Gray]

Add Raspberry Pi Compute Module 3+ to list of models, the revision code
is 0x10 according to the list on raspberrypi.org.

Signed-off-by: Jonathan Gray 
---
 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 153a1fdcb7..c118250740 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
false,
},
+   [0x10] = {
+   "Compute Module 3+",
+   DTB_DIR "bcm2837-rpi-cm3-plus.dtb",
+   false,
+   },
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] efi_loader: Make RTS relocation more robust

[Jonathan Gray]

On Tue, Dec 11, 2018 at 10:00:42AM +0100, Alexander Graf wrote:
> While changing the RTS alignment to 64KB in commit 7a82c3051c8f
> ("efi_loader: Align runtime section to 64kb") the relocation code
> started to break.
> 
> The reason for that is that we didn't actually look at the real
> relocation data. We merely took the RUNTIME_CODE section as a
> hint and started to relocate based on self calculated data from
> that point on. That calculation was now out of sync though.
> 
> To ensure we're not running into such a situation again, this patch
> makes the runtime relocation code a bit more robust. We can just
> trust the phys/virt hints from the payload. We also should check that
> we really only have a single section, as the code doesn't handle
> multiple code relocations yet.
> 
> Fixes: 7a82c3051c8f ("efi_loader: Align runtime section to 64kb")
> Reported-by: Heinrich Schuchardt 
> Reported-by: Loic Devulder 
> Signed-off-by: Alexander Graf 

This fixes booting OpenBSD on qemu-system-aarch64 where previously it
would drop into the kernel debugger when probing efi runtime services.

Tested-by: Jonathan Gray 

> 
> ---
> 
> v1 -> v2:
> 
>   - Add more verbose comment explaining why we have the
> sanity check.
> ---
>  lib/efi_loader/efi_runtime.c | 34 +++---
>  1 file changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index 95844efdb0..fff93f0960 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -436,14 +436,42 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
>   uint32_t descriptor_version,
>   struct efi_mem_desc *virtmap)
>  {
> - ulong runtime_start = (ulong)&__efi_runtime_start &
> -   ~(ulong)EFI_PAGE_MASK;
>   int n = memory_map_size / descriptor_size;
>   int i;
> + int rt_code_sections = 0;
>  
>   EFI_ENTRY("%lx %lx %x %p", memory_map_size, descriptor_size,
> descriptor_version, virtmap);
>  
> + /*
> +  * TODO:
> +  * Further down we are cheating. While really we should implement
> +  * SetVirtualAddressMap() events and ConvertPointer() to allow
> +  * dynamically loaded drivers to expose runtime services, we don't
> +  * today.
> +  *
> +  * So let's ensure we see exactly one single runtime section, as
> +  * that is the built-in one. If we see more (or less), someone must
> +  * have tried adding or removing to that which we don't support yet.
> +  * In that case, let's better fail rather than expose broken runtime
> +  * services.
> +  */
> + for (i = 0; i < n; i++) {
> + struct efi_mem_desc *map = (void*)virtmap +
> +(descriptor_size * i);
> +
> + if (map->type == EFI_RUNTIME_SERVICES_CODE)
> + rt_code_sections++;
> + }
> +
> + if (rt_code_sections != 1) {
> + /*
> +  * We expose exactly one single runtime code section, so
> +  * something is definitely going wrong.
> +  */
> + return EFI_EXIT(EFI_INVALID_PARAMETER);
> + }
> +
>   /* Rebind mmio pointers */
>   for (i = 0; i < n; i++) {
>   struct efi_mem_desc *map = (void*)virtmap +
> @@ -483,7 +511,7 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
>   map = (void*)virtmap + (descriptor_size * i);
>   if (map->type == EFI_RUNTIME_SERVICES_CODE) {
>   ulong new_offset = map->virtual_start -
> -(runtime_start - gd->relocaddr);
> +map->physical_start + gd->relocaddr;
>  
>   efi_runtime_relocate(new_offset, map);
>   /* Once we're virtual, we can no longer handle
> -- 
> 2.12.3
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] tools/file2include: don't use malloc.h for malloc

[Jonathan Gray]

stdlib.h is the header for malloc since at least c89/c90.
Previously this would fail to build on OpenBSD and fallback to the wrong
header:

In file included from u-boot/tools/file2include.c:21:
u-boot/include/malloc.h:875:5: error: function-like macro
  'CONFIG_IS_ENABLED' is not defined

Signed-off-by: Jonathan Gray 
---
 tools/file2include.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/file2include.c b/tools/file2include.c
index b98af30a72..775440cba9 100644
--- a/tools/file2include.c
+++ b/tools/file2include.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /* Size of the blocks written to the compressed file */
 #define BLOCK_SIZE 8
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rpi: add 3 Model A+

[Jonathan Gray]

Add Raspberry Pi 3 Model A+ to list of models, the revision code is 0xE
according to the list on raspberrypi.org.

Signed-off-by: Jonathan Gray 
---
 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 5062486311..153a1fdcb7 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -138,6 +138,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2837-rpi-3-b-plus.dtb",
true,
},
+   [0xE] = {
+   "3 Model A+",
+   DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
+   false,
+   },
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rpi: add URL of official revision code list

[Jonathan Gray]

Replace various third party lists of Raspberry Pi revision codes in a
comment with the list on raspberrypi.org.

Signed-off-by: Jonathan Gray 
---
 board/raspberrypi/rpi/rpi.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 649127c5bf..5062486311 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -68,14 +68,7 @@ struct msg_get_clock_rate {
 #endif
 
 /*
- * 
http://raspberryalphaomega.org.uk/2013/02/06/automatic-raspberry-pi-board-revision-detection-model-a-b1-and-b2/
- * http://www.raspberrypi.org/forums/viewtopic.php?f=63=32733
- * 
http://git.drogon.net/?p=wiringPi;a=blob;f=wiringPi/wiringPi.c;h=503151f61014418b9c42f4476a6086f75cd4e64b;hb=refs/heads/master#l922
- *
- * In http://lists.denx.de/pipermail/u-boot/2016-January/243752.html
- * ("[U-Boot] [PATCH] rpi: fix up Model B entries") Dom Cobley at the RPi
- * Foundation stated that the following source was accurate:
- * https://github.com/AndrewFromMelbourne/raspberry_pi_revision
+ * 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
  */
 struct rpi_model {
const char *name;
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()

[Jonathan Gray]

On Sun, Sep 23, 2018 at 02:33:47PM +0200, Heinrich Schuchardt wrote:
> Since GRUB patch d0c070179d4d ("arm/efi: Switch to arm64 linux loader",
> 2018-07-09) we do not need a workaround for GRUB on 32bit ARM anymore.
> 
> So let's eliminate function efi_exit_caches().
> 
> This will require Linux distributions to update grub-efi-arm to the GRUB
> git HEAD (a tag containing the aforementioned GRUB patch is not available
> yet).

OpenBSD/armv7 can no longer boot with U-Boot after this commit as
it currently does not explicitly invalidate/flush caches in efiboot.

> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 28 
>  1 file changed, 28 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 2496608981..97eb19cd14 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -26,14 +26,6 @@ LIST_HEAD(efi_obj_list);
>  /* List of all events */
>  LIST_HEAD(efi_events);
>  
> -/*
> - * If we're running on nasty systems (32bit ARM booting into non-EFI Linux)
> - * we need to do trickery with caches. Since we don't want to break the EFI
> - * aware boot path, only apply hacks when loading exiting directly (breaking
> - * direct Linux EFI booting along the way - oh well).
> - */
> -static bool efi_is_direct_boot = true;
> -
>  #ifdef CONFIG_ARM
>  /*
>   * The "gd" pointer lives in a register on ARM and AArch64 that we declare
> @@ -1686,8 +1678,6 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t 
> image_handle,
>  
>   EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data);
>  
> - efi_is_direct_boot = false;
> -
>   /* call the image! */
>   if (setjmp(_obj->exit_jmp)) {
>   /*
> @@ -1795,21 +1785,6 @@ static efi_status_t EFIAPI 
> efi_unload_image(efi_handle_t image_handle)
>   return EFI_EXIT(EFI_SUCCESS);
>  }
>  
> -/**
> - * efi_exit_caches() - fix up caches for EFI payloads if necessary
> - */
> -static void efi_exit_caches(void)
> -{
> -#if defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
> - /*
> -  * Grub on 32bit ARM needs to have caches disabled before jumping into
> -  * a zImage, but does not know of all cache layers. Give it a hand.
> -  */
> - if (efi_is_direct_boot)
> - cleanup_before_linux();
> -#endif
> -}
> -
>  /**
>   * efi_exit_boot_services() - stop all boot services
>   * @image_handle: handle of the loaded image
> @@ -1863,9 +1838,6 @@ static efi_status_t EFIAPI 
> efi_exit_boot_services(efi_handle_t image_handle,
>  
>   board_quiesce_devices();
>  
> - /* Fix up caches for EFI payloads if necessary */
> - efi_exit_caches();
> -
>   /* This stops all lingering devices */
>   bootm_disable_interrupts();
>  
> -- 
> 2.19.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/3] efi_loader: ARM: run EFI payloads non-secure

[Jonathan Gray]

On Sun, Sep 23, 2018 at 01:30:11AM +0200, Heinrich Schuchardt wrote:
> On 09/01/2018 12:21 PM, Alexander Graf wrote:
> > 
> > 
> > On 31.08.18 20:45, Mark Kettenis wrote:
> >>> From: Heinrich Schuchardt 
> >>> Date: Fri, 31 Aug 2018 19:37:25 +0200
> >>>
> >>> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
>  If desired (and possible) switch into HYP mode or non-secure SVC mode
>  before calling the entry point of an EFI application.  This allows
>  U-Boot to provide a usable PSCI implementation and makes it possible
>  to boot kernels into hypervisor mode using an EFI bootloader.
> 
>  Based on diffs from Heinrich Schuchardt and Alexander Graf.
> 
>  Signed-off-by: Mark Kettenis 
> >>>
> >>> bootefi hello fails on vexpress_ca15_tc2_defconfig when run on qemu with
> >>>
> >>> QEMU_AUDIO_DRV=none qemu-system-arm \
> >>> -M vexpress-a15 -cpu cortex-a15 -kernel u-boot \
> >>> -net user -net nic,model=lan9118 \
> >>> -m 1024M --nographic \
> >>> -drive if=sd,file=img.vexpress,media=disk,format=raw
> >>
> >> Works for me with:
> >>
> >> $ qemu-system-arm --version
> >> QEMU emulator version 3.0.0
> >> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
> >>
> >> => bootefi hello
> >> Scanning disks on mmc...
> >> MMC Device 1 not found
> >> MMC Device 2 not found
> >> MMC Device 3 not found
> >> Found 3 disks
> >> WARNING: booting without device tree
> >> ## Starting EFI application at a0008000 ...
> >> WARNING: using memory device/image path, this may confuse some payloads!
> >> Hello, world!
> >> Running on UEFI 2.7
> >> Have SMBIOS table
> >> Load options: 
> >> ## Application terminated, r = 0
> >>
> >> That is with CONFIG_CMD_BOOTEFI_HELLO=y added to the
> >> vexpress_ca15_tc2_defconfig of course.
> >>
> >>> Bisection points to
> >>> efi_loader: ARM: run EFI payloads non-secure
> >>> commit dc500c369486fbe04000fd325c46bb309e4a1827
> >>
> >> That suggests an issue with emulation if the mode switching
> >> instructions or HYP support in qemu.  Or a toolchain issue of course.
> > 
> > Or maybe Heinrich's QEMU version starts up in a different EL mode?
> > 
> > 
> > Alex
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> > 
> The problem is reproducible with qemu 3.0.0.
> 
> git reset --hard dc500c369486fbe04000fd325c46bb309e4a1827
> 
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -2,7 +2,6 @@ config EFI_LOADER
> bool "Support running EFI Applications in U-Boot"
> depends on (ARM || X86 || RISCV) && OF_LIBFDT
> # We do not support bootefi booting ARMv7 in non-secure mode
> -   depends on !ARMV7_NONSEC
> # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
> depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
> # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
> 
> make vexpress_ca15_tc2_defconfig
> 
> Set CONFIG_CMD_BOOTEFI_HELLO=y
> 
> export CROSS_COMPILE=arm-linux-gnueabihf-
> make
> 
> QEMU_AUDIO_DRV=none qemu-system-arm \
> -M vexpress-a15 -cpu cortex-a15 -kernel u-boot \
> -netdev \
> user,id=net0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
> -net nic,model=lan9118,netdev=net0 \
> -m 1024M --nographic \
> -drive if=sd,file=img.vexpress,media=disk,format=raw
> 
> => bootefi hello
> Scanning disks on mmc...
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 2 disks
> WARNING: booting without device tree
> ## Starting EFI application at a0008000 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> 
> No further output after this line :(

bootefi hello works fine with 2018.09 and qemu 3.0 here

gmake PYTHON=python2.7 CROSS_COMPILE=arm-none-eabi- vexpress_ca15_tc2_defconfig 
O=build/vexpress
gmake PYTHON=python2.7 CROSS_COMPILE=arm-none-eabi- O=build/vexpress menuconfig
gmake PYTHON=python2.7 CROSS_COMPILE=arm-none-eabi- O=build/vexpress all

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arm-none-eabi/6.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: 
/usr/obj/ports/arm-none-eabi-gcc-linaro-6.3.2017.02-arm/gcc-linaro-6.3-2017.02/configure
 --enable-languages=c,c++ --enable-multilib --enable-interwork 
--with-gmp=/usr/local --with-newlib --disable-lto --enable-cpp 
--target=arm-none-eabi --disable-shared --disable-nls --disable-werror 
--prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man 
--infodir=/usr/local/info --localstatedir=/var --disable-silent-rules 
--disable-gtk-doc
Thread model: single
gcc version 6.3.1 20170109 (Linaro GCC 6.3-2017.02)

$ qemu-system-arm --version
QEMU emulator version 3.0.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

qemu-system-arm -m 1024 -M vexpress-a15 -kernel build/vexpress/u-boot -serial 
stdio

U-Boot 2018.09-1-g2a9fbd55c3 

Re: [U-Boot] [PATCH] ARM: qemu-arm: Fix qemu_arm64_defconfig for QEMU 3.0

[Jonathan Gray]

On Tue, Sep 04, 2018 at 06:16:52PM +0300, Tuomas Tynkkynen wrote:
> QEMU 3.0 introduced additional memory-mapped regions for PCI-E ECAM and
> MMIO. Thus we need to add them to our MMU map or U-Boot will crash with
> a Synchronous Abort during PCI-E probing when it tries to access the
> unmapped ECAM memory area.
> 
> Reported-by: Jonathan Gray 
> Signed-off-by: Tuomas Tynkkynen 

Thanks, qemu-system-aarch64 -M virt works without having to disable
highmem with this.

Tested-by: Jonathan Gray 

> ---
>  board/emulation/qemu-arm/qemu-arm.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> b/board/emulation/qemu-arm/qemu-arm.c
> index 1f5a33d520..812c90636d 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -17,7 +17,7 @@ static struct mm_region qemu_arm64_mem_map[] = {
>   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>PTE_BLOCK_INNER_SHARE
>   }, {
> - /* Peripherals */
> + /* Lowmem peripherals */
>   .virt = 0x0800UL,
>   .phys = 0x0800UL,
>   .size = 0x3800,
> @@ -31,6 +31,22 @@ static struct mm_region qemu_arm64_mem_map[] = {
>   .size = 255UL * SZ_1G,
>   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>PTE_BLOCK_INNER_SHARE
> + }, {
> + /* Highmem PCI-E ECAM memory area */
> + .virt = 0x401000ULL,
> + .phys = 0x401000ULL,
> + .size = 0x1000,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +  PTE_BLOCK_NON_SHARE |
> +  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* Highmem PCI-E MMIO memory area */
> + .virt = 0x80ULL,
> + .phys = 0x80ULL,
> + .size = 0x80ULL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +  PTE_BLOCK_NON_SHARE |
> +  PTE_BLOCK_PXN | PTE_BLOCK_UXN
>   }, {
>   /* List terminator */
>   0,
> -- 
> 2.16.3
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] doc: qemu-arm: Drop highmem=off references

[Jonathan Gray]

On Mon, May 14, 2018 at 06:47:52PM +0300, Tuomas Tynkkynen wrote:
> Now that U-Boot works fine with highmem enabled, there is no need to
> tell users to disable highmem.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  doc/README.qemu-arm | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/doc/README.qemu-arm b/doc/README.qemu-arm
> index 6f6f07d8bb..260165638a 100644
> --- a/doc/README.qemu-arm
> +++ b/doc/README.qemu-arm
> @@ -39,13 +39,12 @@ Running U-Boot
>  The minimal QEMU command line to get U-Boot up and running is:
>
>  - For ARM:
> -qemu-system-arm -machine virt,highmem=off -bios u-boot.bin
> +qemu-system-arm -machine virt -bios u-boot.bin
>
>  - For AArch64:
> -qemu-system-aarch64 -machine virt,highmem=off -cpu cortex-a57 -bios 
> u-boot.bin
> +qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin
>
> -The 'highmem=off' parameter to the 'virt' machine is required for PCI to work
> -in U-Boot. Also, for some odd reason qemu-system-aarch64 needs to be 
> explicitly
> +Note that for some odd reason qemu-system-aarch64 needs to be explicitly
>  told to use a 64-bit CPU or it will boot in 32-bit mode.
>
>  Additional peripherals that have been tested to work in both U-Boot and Linux

Something has changed as qemu 3.0 requires highmem=off again.
qemu 2.12.0 works without highmem=off.

$ qemu-system-aarch64 --version
QEMU emulator version 3.0.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ qemu-system-aarch64 -M virt -cpu cortex-a57 -bios u-boot.bin -serial stdio

U-Boot 2018.09-rc3 (Sep 04 2018 - 13:03:12 +1000)

DRAM:  128 MiB
In:pl011@900
Out:   pl011@900
Err:   pl011@900
Net:   No ethernet found.
"Synchronous Abort" handler, esr 0x9605
elr: 000258e0 lr : 0002589c (reloc)
elr: 47f978e0 lr : 47f9789c
x0 : 0040100e x1 : 
x2 : 0040100e x3 : 46e608c8
x4 : 00401000 x5 : 
x6 : 47f9889c x7 : 0002
x8 : 0003 x9 : 0004
x10: 46e60de8 x11: 152c
x12: 46e6089c x13: 1200
x14: 46e6092c x15: 46e60de8
x16:  x17: 
x18: 46f61de8 x19: 46e60940
x20:  x21: 47fcc0a8
x22: 46f62450 x23: 47fcc680
x24: ff00 x25: 
x26: 47fcc000 x27: 
x28:  x29: 46e608a0

Resetting CPU ...

resetting ...

$ qemu-system-aarch64 -M virt,highmem=off -cpu cortex-a57 -bios u-boot.bin 
-serial stdio

U-Boot 2018.09-rc3 (Sep 04 2018 - 13:03:12 +1000)

DRAM:  128 MiB
In:pl011@900
Out:   pl011@900
Err:   pl011@900
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
scanning bus for devices...

Device 0: unknown device
=> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rsa: Fix LibreSSL before v2.7.0

[Jonathan Gray]

On Wed, Jul 25, 2018 at 10:13:03PM -0400, nom...@palism.com wrote:
> From: Caliph Nomble 
> 
> Fix LibreSSL compilation for versions before v2.7.0.
> 
> Signed-off-by: Caliph Nomble 
> ---
> Tested compilation on LibreSSL v2.7.4 and v2.6.4 with no new errors or
> warnings.

Builds on OpenBSD -current with 2.8.0.  bcm7445 config resulted in
building it.

Could be 0x207fL not 0x0207fL to match the other uses but that
is just cosmetic.

Reviewed-by: Jonathan Gray 

> 
> Changes for v2:
> - fixed commit message conventions
> - fixed coding style
> 
>  lib/rsa/rsa-sign.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index cfe09cc94c..05ac67b822 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -20,7 +20,8 @@
>  #define HAVE_ERR_REMOVE_THREAD_STATE
>  #endif
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
>  static void RSA_get0_key(const RSA *r,
>   const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
>  {
> @@ -299,7 +300,8 @@ static int rsa_init(void)
>  {
>   int ret;
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
>   ret = SSL_library_init();
>  #else
>   ret = OPENSSL_init_ssl(0, NULL);
> @@ -308,7 +310,8 @@ static int rsa_init(void)
>   fprintf(stderr, "Failure to init SSL library\n");
>   return -1;
>   }
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
>   SSL_load_error_strings();
>  
>   OpenSSL_add_all_algorithms();
> @@ -354,7 +357,8 @@ err_set_rsa:
>  err_engine_init:
>   ENGINE_free(e);
>  err_engine_by_id:
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
>   ENGINE_cleanup();
>  #endif
>   return ret;
> @@ -362,7 +366,8 @@ err_engine_by_id:
>  
>  static void rsa_remove(void)
>  {
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
>   CRYPTO_cleanup_all_ex_data();
>   ERR_free_strings();
>  #ifdef HAVE_ERR_REMOVE_THREAD_STATE
> @@ -432,7 +437,8 @@ static int rsa_sign_with_key(RSA *rsa, struct 
> checksum_algo *checksum_algo,
>   ret = rsa_err("Could not obtain signature");
>   goto err_sign;
>   }
> - #if OPENSSL_VERSION_NUMBER < 0x1010L
> + #if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
>   EVP_MD_CTX_cleanup(context);
>   #else
>   EVP_MD_CTX_reset(context);
> -- 
> 2.16.4
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix LibreSSL before v2.7.0

[Jonathan Gray]

On Tue, Jul 24, 2018 at 07:47:48PM -0400, nom...@palism.com wrote:
> From: Nomble 
> 
> Signed-off-by: Nomble 
> Signed-off-by: Caliph Nomble 
> ---
>  lib/rsa/rsa-sign.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index cfe09cc94c..ab8572894d 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -20,7 +20,7 @@
>  #define HAVE_ERR_REMOVE_THREAD_STATE
>  #endif
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || 
> (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)

This should be put on a newline like the use in tools/kwbimage.c and
tools/mxsimage.c same with other uses.

>  static void RSA_get0_key(const RSA *r,
>   const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
>  {
> @@ -299,7 +299,7 @@ static int rsa_init(void)
>  {
>   int ret;
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)

LibreSSL has OPENSSL_init_ssl() version should be tested

>   ret = SSL_library_init();
>  #else
>   ret = OPENSSL_init_ssl(0, NULL);
> @@ -308,7 +308,7 @@ static int rsa_init(void)
>   fprintf(stderr, "Failure to init SSL library\n");
>   return -1;
>   }
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)

This should probably be version tested as well.

>   SSL_load_error_strings();
>  
>   OpenSSL_add_all_algorithms();
> @@ -354,7 +354,7 @@ err_set_rsa:
>  err_engine_init:
>   ENGINE_free(e);
>  err_engine_by_id:
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || 
> (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
>   ENGINE_cleanup();
>  #endif
>   return ret;
> @@ -362,7 +362,7 @@ err_engine_by_id:
>  
>  static void rsa_remove(void)
>  {
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || 
> (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
>   CRYPTO_cleanup_all_ex_data();
>   ERR_free_strings();
>  #ifdef HAVE_ERR_REMOVE_THREAD_STATE
> @@ -432,7 +432,8 @@ static int rsa_sign_with_key(RSA *rsa, struct 
> checksum_algo *checksum_algo,
>   ret = rsa_err("Could not obtain signature");
>   goto err_sign;
>   }
> - #if OPENSSL_VERSION_NUMBER < 0x1010L
> +
> + #if OPENSSL_VERSION_NUMBER < 0x1010L || 
> (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
>   EVP_MD_CTX_cleanup(context);
>   #else
>   EVP_MD_CTX_reset(context);
> -- 
> 2.16.4
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] raspberrypi compute module3 emmc not usable

[Jonathan Gray]

On Tue, Jul 10, 2018 at 10:37:19PM +0200, Belisko Marek wrote:
> Hello,
> 
> I'm trying to use u-boot on CM3 (which contains eMMC) to boot kernel.
> I'm using u-boot 2018.05 and it can start fine like:
> U-Boot 2018.05 (Jul 10 2018 - 20:32:05 +)
> 
> DRAM:  948 MiB
> RPI Compute Module 3 (0xa220a0)
> MMC:   sdhci@7e30: 0
> Loading Environment from FAT... unable to select a mode
> ** No partition table - mmc 0 **
> Failed (-5)
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:   scanning bus 0 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> U-Boot>
> U-Boot>
> U-Boot>
> U-Boot> mmc info
> Device: sdhci@7e30
> Manufacturer ID: 15
> OEM: 100
> Name: 4FPD3
> Bus Speed: 5200
> Mode : MMC legacy
> Rd Block Len: 512
> MMC version 5.0
> High Capacity: Yes
> Capacity: 3.6 GiB
> Bus Width: 1-bit
> Erase Group Size: 512 KiB
> HC WP Group Size: 8 MiB
> User Capacity: 3.6 GiB WRREL
> Boot Capacity: 4 MiB ENH
> RPMB Capacity: 512 KiB ENH
> U-Boot> mmc part
> ## Unknown partition table type 0
> U-Boot> mmc read $loadaddr 0 2
> 
> but reading from eMMC fails with:
> 
> MMC read: dev # 0, block # 0, count 2 ... 0 blocks read: ERROR
> 
> so it looks like eMMC is not properly working with CM3 in this
> version? Any ideas what to check to have it working before I dig to
> debugging session ;). Thanks.

You should give 2018.07 a try, which includes a change for a problem
reported by someone with a CM3.

commit 79fd08f7456c7d12b04ef39e51d84d9981599c3a
Author: Alexander Graf 
Date:   Wed May 23 22:24:51 2018 +0200

mmc: Unirqify bcm2835_sdhost and fix writes

The bcm2835 sdhost driver has a problem with "write multiple" commands.
It seems to boil down to the fact that the controller dislikes its FIFO
to get drained at the end of a block when a write multiple blocks command
is in flight.

The easy fix is to simply get rid of all the IRQ driven logic and make
the driver push as much data into the FIFO as it can. That way we never
drain and we never run into the problem.

Reported-by: Jan Leonhardt 
Signed-off-by: Alexander Graf 

 drivers/mmc/bcm2835_sdhost.c | 265 
++
 1 file changed, 47 insertions(+), 218 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rsa: Support LibreSSL in rsa-sign.c

[Jonathan Gray]

On Wed, Jun 27, 2018 at 12:33:05PM +0200, parazyd wrote:
> At present rsa-sign.c can not be compiled with LibreSSL older than
> 2.7.0. This commit adjusts the guards in the rsa-sign.c to check for
> LiBRESSL_VERSION_NUMBER where necessary.

These tests are wrong, an undefined cpp macro will be 0 so with
OpenSSL >= 1.1 the 'LIBRESSL_VERSION_NUMBER < 0x207fL' test
will pass as LIBRESSL_VERSION_NUMBER is not defined.

match the use in tools/kwbimage.c and tools/mxsimage.c

#if OPENSSL_VERSION_NUMBER < 0x1010L || \
(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x207fL)

> 
> Signed-off-by: parazyd 
> ---
>  lib/rsa/rsa-sign.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index cfe09cc94c..ff866c6045 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -20,7 +20,7 @@
>  #define HAVE_ERR_REMOVE_THREAD_STATE
>  #endif
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || LIBRESSL_VERSION_NUMBER < 
> 0x207fL
>  static void RSA_get0_key(const RSA *r,
>   const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
>  {
> @@ -299,7 +299,7 @@ static int rsa_init(void)
>  {
>   int ret;
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || LIBRESSL_VERSION_NUMBER < 
> 0x207fL
>   ret = SSL_library_init();
>  #else
>   ret = OPENSSL_init_ssl(0, NULL);
> @@ -432,7 +432,7 @@ static int rsa_sign_with_key(RSA *rsa, struct 
> checksum_algo *checksum_algo,
>   ret = rsa_err("Could not obtain signature");
>   goto err_sign;
>   }
> - #if OPENSSL_VERSION_NUMBER < 0x1010L
> + #if OPENSSL_VERSION_NUMBER < 0x1010L || LIBRESSL_VERSION_NUMBER < 
> 0x207fL
>   EVP_MD_CTX_cleanup(context);
>   #else
>   EVP_MD_CTX_reset(context);
> -- 
> 2.18.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rsa: Support LibreSSL in rsa-sign.c

[Jonathan Gray]

On Tue, Jun 26, 2018 at 07:49:47AM +0200, parazyd wrote:
> This commit will allow rsa-sign.c to be compiled when LibreSSL is used
> instead of OpenSSL.

It isn't clear what version of LibreSSL you are using but this is
wrong.  The latest LibreSSL has RSA_get0_key(), OPENSSL_init_ssl() and
EVP_MD_CTX_reset().

> 
> Signed-off-by: parazyd 
> ---
>  lib/rsa/rsa-sign.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index cfe09cc94c..e835dc944b 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -20,7 +20,7 @@
>  #define HAVE_ERR_REMOVE_THREAD_STATE
>  #endif
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || LIBRESSL_VERSION_NUMBER
>  static void RSA_get0_key(const RSA *r,
>   const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
>  {
> @@ -299,7 +299,7 @@ static int rsa_init(void)
>  {
>   int ret;
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || LIBRESSL_VERSION_NUMBER
>   ret = SSL_library_init();
>  #else
>   ret = OPENSSL_init_ssl(0, NULL);
> @@ -432,7 +432,7 @@ static int rsa_sign_with_key(RSA *rsa, struct 
> checksum_algo *checksum_algo,
>   ret = rsa_err("Could not obtain signature");
>   goto err_sign;
>   }
> - #if OPENSSL_VERSION_NUMBER < 0x1010L
> + #if OPENSSL_VERSION_NUMBER < 0x1010L || LIBRESSL_VERSION_NUMBER
>   EVP_MD_CTX_cleanup(context);
>   #else
>   EVP_MD_CTX_reset(context);
> -- 
> 2.18.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC

[Jonathan Gray]

On Mon, May 14, 2018 at 11:28:38AM +0200, Wadim Egorov wrote:
> Hi,
> 
> 
> Am 08.05.2018 um 10:05 schrieb Dr. Philipp Tomsich:
> > Looks like the designware GMAC driver is trying to enable a clock and
> > can???t deal with the -ENOENT.  Could you try to see which clock it is
> > requesting and add the necessary entries in the clock-enable function?
> >
> > If you have a patch, I???ll try to prioritise it, so we get these 
> > regressions
> > cleaned up quickly (note that these had all been in rc3???if we???d known
> > earlier, I could have reverted them out for the release).
> >
> > @Wadim: could you please also look into this, as your board should have
> > similar problems (unless your device-tree is very different). 
> unfortunately I am not able to test ethernet on our board right now,
> because there are a few things missing in the designware/gmac part.
> But someone is working on it right now :)
> 
> Anyway, it looks like Jonathan fixed the problem, right?
> 
> Regards,
> Wadim

The patch I sent out works for me.  Hasn't landed in u-boot-rockchip or
master yet though.

> 
> >
> > Thanks,
> > Philipp.
> >
> >> On 8 May 2018, at 09:51, Jonathan Gray <j...@jsg.id.au> wrote:
> >>
> >> On Thu, Apr 26, 2018 at 09:05:33AM +0200, Philipp Tomsich wrote:
> >>>> The generic ehci-driver (ehci-generic.c) will try to enable the clocks
> >>>> listed in the DTSI. If this fails (e.g. due to clk_enable not being
> >>>> implemented in a driver and -ENOSYS being returned by the clk-uclass),
> >>>> the driver will bail our and print an error message.
> >>>>
> >>>> This implements a minimal clk_enable for the RK3288 and supports the
> >>>> clocks mandatory for the EHCI controllers; as these are enabled by
> >>>> default we simply return success.
> >>>>
> >>>> Signed-off-by: Wadim Egorov <w.ego...@phytec.de>
> >>>> Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
> >>>> Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
> >>>> ---
> >>>> drivers/clk/rockchip/clk_rk3288.c | 13 +
> >>>> 1 file changed, 13 insertions(+)
> >>>>
> >>> Applied to u-boot-rockchip, thanks!
> >> This change broke Ethernet on tinker-rk3288.
> >>
> >> U-Boot 2018.05-2-g6ea9f3dd70 (May 08 2018 - 17:21:32 +1000)
> >>
> >> Model: Tinker-RK3288
> >> DRAM:  2 GiB
> >> MMC:   dwmmc@ff0c: 1
> >> Loading Environment from MMC... *** Warning - bad CRC, using default 
> >> environment
> >>
> >> Failed (-5)
> >> In:serial
> >> Out:   serial
> >> Err:   serial
> >> Model: Tinker-RK3288
> >> Net:   failed to enable clock 0
> >> No ethernet found.
> >>
> >> After reverting it:
> >>
> >> U-Boot 2018.05-3-g338bfe2fbf (May 08 2018 - 17:40:09 +1000)
> >>
> >> Model: Tinker-RK3288
> >> DRAM:  2 GiB
> >> MMC:   dwmmc@ff0c: 1
> >> Loading Environment from MMC... *** Warning - bad CRC, using default 
> >> environment
> >>
> >> Failed (-5)
> >> In:serial
> >> Out:   serial
> >> Err:   serial
> >> Model: Tinker-RK3288
> >> Net:   eth0: ethernet@ff29
> >> Hit any key to stop autoboot:  0
> >>
> >> If the default case returned ENOSYS or ENOTSUPP instead of ENOENT it
> >> would work given the changes that were made last time this broke.
> >>
> >> commit 1693a577be14a92e61563bad306aa11a359757f5
> >> Author: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
> >> Date:   Tue Feb 6 17:12:09 2018 +0300
> >>
> >>NET: designware: fix clock enable
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Jonathan Gray]

Add back part of patch send out as
'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
gotten lost when it got merged to set SYS_NS16550_MEM32.

Allows serial output to work on tinker-rk3288 again after
c3c0331db1fb7b1f4ff41e144fc04353b37c785c.

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
---
 include/configs/rockchip-common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index dee82ca99d..68e1105a4b 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -7,6 +7,8 @@
 #define _ROCKCHIP_COMMON_H_
 #include 
 
+#define CONFIG_SYS_NS16550_MEM32
+
 #ifndef CONFIG_SPL_BUILD
 
 /* First try to boot from SD (index 0), then eMMC (index 1) */
-- 
2.16.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: enable SYS_NS16550 for all SoCs by default

[Jonathan Gray]

On Tue, May 08, 2018 at 09:41:32AM +0200, Dr. Philipp Tomsich wrote:
> Kever,
> 
> Could you analyse and provide (against master) a patch for this?
> We???ll need to catch any left-overs from your changes at the start of the 
> cycle
> before we try to merge any of the more invasive changes you have in-flight.
> 
> Thanks,
> Philipp.

The patch in https://patchwork.ozlabs.org/patch/900546/ had a change in
include/configs/rockchip-common.h which was not included in the commit
that made it into to tree as c3c0331db1fb7b1f4ff41e144fc04353b37c785c.

After adding that back it works.

diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index dee82ca99d..68e1105a4b 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -7,6 +7,8 @@
 #define _ROCKCHIP_COMMON_H_
 #include 
 
+#define CONFIG_SYS_NS16550_MEM32
+
 #ifndef CONFIG_SPL_BUILD
 
 /* First try to boot from SD (index 0), then eMMC (index 1) */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rockchip: clk: rk3288: handle clk_enable requests for GMAC

[Jonathan Gray]

Since b0ba1e7e9d9b9441a18048ec67a3b3100c096975
(rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC)
Ethernet no longer probes on RK3288.

Add no-ops for GMAC clocks observed to be requested which match the
clk_enable cases in RK3368 and RK3399.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: Wadim Egorov <w.ego...@phytec.de>
Cc: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
---
 drivers/clk/rockchip/clk_rk3288.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3288.c 
b/drivers/clk/rockchip/clk_rk3288.c
index 9375681187..4a6e5c7113 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -898,6 +898,16 @@ static int rk3288_clk_enable(struct clk *clk)
case HCLK_USBHOST0:
case HCLK_HSIC:
return 0;
+
+   case SCLK_MAC:
+   case SCLK_MAC_RX:
+   case SCLK_MAC_TX:
+   case SCLK_MACREF:
+   case SCLK_MACREF_OUT:
+   case ACLK_GMAC:
+   case PCLK_GMAC:
+   /* Required to successfully probe the Designware GMAC driver */
+   return 0;
}
 
debug("%s: unsupported clk %ld\n", __func__, clk->id);
-- 
2.16.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC

[Jonathan Gray]

On Thu, Apr 26, 2018 at 09:05:33AM +0200, Philipp Tomsich wrote:
> > The generic ehci-driver (ehci-generic.c) will try to enable the clocks
> > listed in the DTSI. If this fails (e.g. due to clk_enable not being
> > implemented in a driver and -ENOSYS being returned by the clk-uclass),
> > the driver will bail our and print an error message.
> > 
> > This implements a minimal clk_enable for the RK3288 and supports the
> > clocks mandatory for the EHCI controllers; as these are enabled by
> > default we simply return success.
> > 
> > Signed-off-by: Wadim Egorov 
> > Acked-by: Philipp Tomsich 
> > Reviewed-by: Philipp Tomsich 
> > ---
> >  drivers/clk/rockchip/clk_rk3288.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> 
> Applied to u-boot-rockchip, thanks!

This change broke Ethernet on tinker-rk3288.

U-Boot 2018.05-2-g6ea9f3dd70 (May 08 2018 - 17:21:32 +1000)

Model: Tinker-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed (-5)
In:serial
Out:   serial
Err:   serial
Model: Tinker-RK3288
Net:   failed to enable clock 0
No ethernet found.

After reverting it:

U-Boot 2018.05-3-g338bfe2fbf (May 08 2018 - 17:40:09 +1000)

Model: Tinker-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed (-5)
In:serial
Out:   serial
Err:   serial
Model: Tinker-RK3288
Net:   eth0: ethernet@ff29
Hit any key to stop autoboot:  0

If the default case returned ENOSYS or ENOTSUPP instead of ENOENT it
would work given the changes that were made last time this broke.

commit 1693a577be14a92e61563bad306aa11a359757f5
Author: Eugeniy Paltsev 
Date:   Tue Feb 6 17:12:09 2018 +0300

NET: designware: fix clock enable
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: enable SYS_NS16550 for all SoCs by default

[Jonathan Gray]

On Thu, Apr 26, 2018 at 09:05:37AM +0200, Philipp Tomsich wrote:
> > All rockchip SoCs can use ns16550 driver, enable it for all
> > and set SYS_NS16550_MEM32 for all SoCs.
> > 
> > Version-changes: 2
> > - use imply instead of select
> > 
> > Signed-off-by: Kever Yang 
> > Acked-by: Philipp Tomsich 
> > Reviewed-by: Philipp Tomsich 
> > ---
> > 
> > Changes in v2: None
> > 
> >  arch/arm/Kconfig  | 1 +
> >  arch/arm/mach-rockchip/Kconfig| 1 -
> >  include/configs/rk3036_common.h   | 3 ---
> >  include/configs/rk3128_common.h   | 2 --
> >  include/configs/rk3188_common.h   | 2 --
> >  include/configs/rk322x_common.h   | 1 -
> >  include/configs/rk3288_common.h   | 2 --
> >  include/configs/rk3328_common.h   | 2 --
> >  include/configs/rk3368_common.h   | 2 --
> >  include/configs/rk3399_common.h   | 2 --
> >  include/configs/rockchip-common.h | 2 ++
> >  include/configs/rv1108_common.h   | 3 ---
> >  12 files changed, 3 insertions(+), 20 deletions(-)
> > 
> 
> Applied to u-boot-rockchip, thanks!

With U-Boot 2018.05 there is no serial console output on tinker-rk3288,
a regression from 2018.03.  I have bisected it to this commit.

Reverting c3c0331db1fb7b1f4ff41e144fc04353b37c785c and
eb3d707e99fcd2213d5f8f0fe4ae53ad416b377e restores serial output with
2018.05.

c3c0331db1fb7b1f4ff41e144fc04353b37c785c is the first bad commit
commit c3c0331db1fb7b1f4ff41e144fc04353b37c785c
Author: Kever Yang 
Date:   Thu Apr 19 11:37:09 2018 +0800

rockchip: enable SYS_NS16550 for all SoCs by default

All rockchip SoCs can use ns16550 driver, enable it for all
and set SYS_NS16550_MEM32 for all SoCs.

Version-changes: 2
- use imply instead of select

Signed-off-by: Kever Yang 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 

:04 04 f7cc8b28ae8179fdc15896bbb55279f205a54008 
d07108bbf467735f31f31c083a9068dff71da247 M  arch
:04 04 d0a0422fc55afdcb5abb82f24b9a0af8de3d39a6 
33c7fcf6f28f44a8c416f95313e7a30b2f73f8f0 M  include
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rsa-sign: Fix build against libressl

[Jonathan Gray]

On Wed, Apr 18, 2018 at 10:37:43PM +0200, Hauke Mehrtens wrote:
> Libressl implements the OpenSSL 1.1 API partially and improved the
> support with version 2.7. For some code we have to take use the OpenSSL
> 1.0 API and for some parts the OpenSSL 1.1 API can be used.
> This was compile tested against libressl 2.6.4 and 2.7.2.

The parts that don't test LIBRESSL_VERSION_NUMBER look suspect.

> 
> Signed-off-by: Hauke Mehrtens 
> ---
>  lib/rsa/rsa-sign.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index 1da4ef7fff..b2a4446d83 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -21,7 +21,8 @@
>  #define HAVE_ERR_REMOVE_THREAD_STATE
>  #endif
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x207fL)
>  static void RSA_get0_key(const RSA *r,
>   const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
>  {
> @@ -300,7 +301,8 @@ static int rsa_init(void)
>  {
>   int ret;
>  
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x207fL)
>   ret = SSL_library_init();
>  #else
>   ret = OPENSSL_init_ssl(0, NULL);
> @@ -309,7 +311,7 @@ static int rsa_init(void)
>   fprintf(stderr, "Failure to init SSL library\n");
>   return -1;
>   }
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
>   SSL_load_error_strings();
>  
>   OpenSSL_add_all_algorithms();

Shouldn't this block also be gated by VERSION < 0x207fL as 
SSL_library_init()
covers it?

> @@ -355,7 +357,7 @@ err_set_rsa:
>  err_engine_init:
>   ENGINE_free(e);
>  err_engine_by_id:
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L ||  defined(LIBRESSL_VERSION_NUMBER)
>   ENGINE_cleanup();
>  #endif
>   return ret;
> @@ -363,7 +365,7 @@ err_engine_by_id:
>  
>  static void rsa_remove(void)
>  {
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
>   CRYPTO_cleanup_all_ex_data();
>   ERR_free_strings();
>  #ifdef HAVE_ERR_REMOVE_THREAD_STATE
> @@ -433,7 +435,8 @@ static int rsa_sign_with_key(RSA *rsa, struct 
> checksum_algo *checksum_algo,
>   ret = rsa_err("Could not obtain signature");
>   goto err_sign;
>   }
> - #if OPENSSL_VERSION_NUMBER < 0x1010L
> + #if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + defined(LIBRESSL_VERSION_NUMBER)
>   EVP_MD_CTX_cleanup(context);
>   #else
>   EVP_MD_CTX_reset(context);

EVP_MD_CTX_reset is present in recent LibreSSL as well and
should be used here.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rpi: Complete table of models with new revision code scheme

[Jonathan Gray]

In the model table for the new revision code encoding documented in
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
add the entries for old models with the new scheme and add CM3 which
only appears in the new scheme.

A device tree for CM3 is not currently upstreamed in linux.  When that
happens the name will likely have to be adjusted in the table.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 board/raspberrypi/rpi/rpi.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 279a9c3cda..de8e308f6c 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -91,11 +91,36 @@ static const struct rpi_model rpi_model_unknown = {
 };
 
 static const struct rpi_model rpi_models_new_scheme[] = {
+   [0x0] = {
+   "Model A",
+   DTB_DIR "bcm2835-rpi-a.dtb",
+   false,
+   },
+   [0x1] = {
+   "Model B",
+   DTB_DIR "bcm2835-rpi-b.dtb",
+   true,
+   },
+   [0x2] = {
+   "Model A+",
+   DTB_DIR "bcm2835-rpi-a-plus.dtb",
+   false,
+   },
+   [0x3] = {
+   "Model B+",
+   DTB_DIR "bcm2835-rpi-b-plus.dtb",
+   true,
+   },
[0x4] = {
"2 Model B",
DTB_DIR "bcm2836-rpi-2-b.dtb",
true,
},
+   [0x6] = {
+   "Compute Module",
+   DTB_DIR "bcm2835-rpi-cm.dtb",
+   false,
+   },
[0x8] = {
"3 Model B",
DTB_DIR "bcm2837-rpi-3-b.dtb",
@@ -106,6 +131,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2835-rpi-zero.dtb",
false,
},
+   [0xA] = {
+   "Compute Module 3",
+   DTB_DIR "bcm2837-rpi-cm3.dtb",
+   false,
+   },
[0xC] = {
"Zero W",
DTB_DIR "bcm2835-rpi-zero-w.dtb",
-- 
2.16.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] tools/mxsimage: Support building with LibreSSL

[Jonathan Gray]

On Sun, Mar 18, 2018 at 04:03:47PM +0100, Hauke Mehrtens wrote:
> The mxsimage utility fails to compile against LibreSSL version < 2.7.0
> because LibreSSL says it is OpenSSL 2.0, but it does not support the
> complete OpenSSL 1.1 interface.
> 
> LibreSSL defines OPENSSL_VERSION_NUMBER with 0x2000L and therefor
> claims to have an API compatible with OpenSSL 2.0, but it implements
> EVP_MD_CTX_new(), EVP_MD_CTX_free() and EVP_CIPHER_CTX_reset() only
> starting with version 2.7.0, which is not yet released. OpenSSL
> implements this function since version 1.1.0.
> 
> This commit will activate the compatibility code meant for
> OpenSSL < 1.1.0 also for LibreSSL version < 2.7.0.
> 
> Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>

Reviewed-by: Jonathan Gray <j...@jsg.id.au>

> ---
>  tools/mxsimage.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/mxsimage.c b/tools/mxsimage.c
> index 32a7978cae..c8f1f204e3 100644
> --- a/tools/mxsimage.c
> +++ b/tools/mxsimage.c
> @@ -26,7 +26,8 @@
>   * OpenSSL 1.1.0 and newer compatibility functions:
>   * https://wiki.openssl.org/index.php/1.1_API_Changes
>   */
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x207fL)
>  static void *OPENSSL_zalloc(size_t num)
>  {
>   void *ret = OPENSSL_malloc(num);
> -- 
> 2.11.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip: rk3399: set fdtfile

[Jonathan Gray]

On Mon, Mar 19, 2018 at 08:17:49AM +0100, klaus.go...@theobroma-systems.com 
wrote:
> 
> > On 17.03.2018, at 09:48, Mark Kettenis  wrote:
> > 
> > Signed-off-by: Mark Kettenis 
> > Acked-by: Philipp Tomsich 
> > ---
> > include/configs/rk3399_common.h | 1 +
> > 1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/configs/rk3399_common.h 
> > b/include/configs/rk3399_common.h
> > index d700bf2549..9a5de3a7e3 100644
> > --- a/include/configs/rk3399_common.h
> > +++ b/include/configs/rk3399_common.h
> > @@ -59,6 +59,7 @@
> > #include 
> > #define CONFIG_EXTRA_ENV_SETTINGS \
> > ENV_MEM_LAYOUT_SETTINGS \
> > +   "fdtfile=rockchip/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
> > "partitions=" PARTS_DEFAULT \
> > BOOTENV
> > 
> 
> This assumes that the devicetree files in U-Boot and the OS are the same.
> As it???s our goal to keep Linux devicetrees in sync with U-Boot this patch 
> should
> be fine in the long-term. But at the moment this only applies for 
> rk3399-firefly (on
> Linux).
> 
> Mark, where would one find the devicetrees included in OpenBSD?
> I looked in sys/arch/amd64 but couldn???t find any.

The ideal case is the firmware (U-Boot, EDK2 etc) supplies a device tree
and resides on it's own storage.  Then we could have single install
images that work everywhere without having to distribute board specific
U-Boot and dtb files.

As most arm systems aren't ideal there are ports/packages that build
device trees from the linux source and package up those provided
as part of raspberrypi-firmware.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/dtb/
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/raspberrypi-firmware/

Then there are some U-Boot targets with builtin device trees.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/u-boot/
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/u-boot-pinebook/

The parts of the tree that build install images with U-Boot/dtbs:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/armv7/
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/arm64/

> 
> Anyhow, I???m fine with that change.
> 
> Tested-by: Klaus Goger 
> 
> ??? 
> Klaus
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] tools/mxsimage: Support building with LibreSSL

[Jonathan Gray]

On Sun, Mar 18, 2018 at 01:55:29AM +0100, Hauke Mehrtens wrote:
> On 03/18/2018 01:33 AM, Jonathan Gray wrote:
> > On Sat, Mar 17, 2018 at 05:24:47PM +0100, Marek Vasut wrote:
> >> On 03/17/2018 04:09 PM, Hauke Mehrtens wrote:
> >>> On 03/17/2018 03:47 PM, Marek Vasut wrote:
> >>>> On 03/17/2018 01:23 PM, Hauke Mehrtens wrote:
> >>>>> The mxsimage utility fails to compile against LibreSSL because LibreSSL
> >>>>> says it is OpenSSL 2.0, but it does not support the complete OpenSSL 1.1
> >>>>> interface.
> >>>>
> >>>> The mxsimage does support OpenSSL 1.1 , the commit message is confusing.
> >>>> Can you elaborate on that and reword the last part ?
> >>>
> >>> libressl defines the following in version 2.7.4:
> >>> #define OPENSSL_VERSION_NUMBER0x2000L
> >>> #define LIBRESSL_VERSION_NUMBER   0x2060400fL
> >>> see here:
> >>> https://github.com/libressl-portable/openbsd/blob/OPENBSD_6_2/src/lib/libcrypto/opensslv.h
> >>>
> >>> But OPENSSL_zalloc() is not provided by libressl, that is only available
> >>> in OpeSSL 1.1.0 and later.
> >>
> >> So it's libressl that's API-incompatible and thus broken ? OK
> >>
> >> I guess the commit message should mention that and then yes, if
> >> LIBRESSL_VERSION_NUMBER is defined, we should treat it as old version of
> >> OpenSSL.
> > 
> > LibreSSL implements parts of the OpenSSL 1.1 API without breaking
> > backwards compat like OpenSSL did.
> > 
> > The proposed patch to mxsimage.c is wrong as some of these functions
> > are now implemented by LibreSSL.
> > 
> > https://marc.info/?l=openbsd-cvs=151887933725237=2
> > EVP_MD_CTX_new()
> > EVP_MD_CTX_free()
> > EVP_CIPHER_CTX_reset()
> > 
> > OPENSSL_zalloc() is not implemented but it is only used in this ifdef block.
> > 
> > A patch along the lines of the below would be better.
> > 
> > diff --git a/tools/mxsimage.c b/tools/mxsimage.c
> > index 32a7978cae..c8f1f204e3 100644
> > --- a/tools/mxsimage.c
> > +++ b/tools/mxsimage.c
> > @@ -26,7 +26,8 @@
> >   * OpenSSL 1.1.0 and newer compatibility functions:
> >   * https://wiki.openssl.org/index.php/1.1_API_Changes
> >   */
> > -#if OPENSSL_VERSION_NUMBER < 0x1010L
> > +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> > +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> > 0x207fL)
> >  static void *OPENSSL_zalloc(size_t num)
> >  {
> > void *ret = OPENSSL_malloc(num);
> > 
> Yes you are right your patch is better. Now I also found these functions
> in the libressl repository and they will be available with the version
> 2.7.0.
> https://github.com/libressl-portable/openbsd/commit/2443cc9a48b200ef126dba99cbbb2f25937382e0
> https://github.com/libressl-portable/openbsd/commit/651a8b53a2a41bbfc31d665b3f7030109d09606e
> 
> Is this sufficient or should I send a new patch?

I think you'll need to send a v2 for it to get picked up.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] tools/mxsimage: Support building with LibreSSL

[Jonathan Gray]

On Sat, Mar 17, 2018 at 05:24:47PM +0100, Marek Vasut wrote:
> On 03/17/2018 04:09 PM, Hauke Mehrtens wrote:
> > On 03/17/2018 03:47 PM, Marek Vasut wrote:
> >> On 03/17/2018 01:23 PM, Hauke Mehrtens wrote:
> >>> The mxsimage utility fails to compile against LibreSSL because LibreSSL
> >>> says it is OpenSSL 2.0, but it does not support the complete OpenSSL 1.1
> >>> interface.
> >>
> >> The mxsimage does support OpenSSL 1.1 , the commit message is confusing.
> >> Can you elaborate on that and reword the last part ?
> > 
> > libressl defines the following in version 2.7.4:
> > #define OPENSSL_VERSION_NUMBER  0x2000L
> > #define LIBRESSL_VERSION_NUMBER 0x2060400fL
> > see here:
> > https://github.com/libressl-portable/openbsd/blob/OPENBSD_6_2/src/lib/libcrypto/opensslv.h
> > 
> > But OPENSSL_zalloc() is not provided by libressl, that is only available
> > in OpeSSL 1.1.0 and later.
> 
> So it's libressl that's API-incompatible and thus broken ? OK
> 
> I guess the commit message should mention that and then yes, if
> LIBRESSL_VERSION_NUMBER is defined, we should treat it as old version of
> OpenSSL.

LibreSSL implements parts of the OpenSSL 1.1 API without breaking
backwards compat like OpenSSL did.

The proposed patch to mxsimage.c is wrong as some of these functions
are now implemented by LibreSSL.

https://marc.info/?l=openbsd-cvs=151887933725237=2
EVP_MD_CTX_new()
EVP_MD_CTX_free()
EVP_CIPHER_CTX_reset()

OPENSSL_zalloc() is not implemented but it is only used in this ifdef block.

A patch along the lines of the below would be better.

diff --git a/tools/mxsimage.c b/tools/mxsimage.c
index 32a7978cae..c8f1f204e3 100644
--- a/tools/mxsimage.c
+++ b/tools/mxsimage.c
@@ -26,7 +26,8 @@
  * OpenSSL 1.1.0 and newer compatibility functions:
  * https://wiki.openssl.org/index.php/1.1_API_Changes
  */
-#if OPENSSL_VERSION_NUMBER < 0x1010L
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x207fL)
 static void *OPENSSL_zalloc(size_t num)
 {
void *ret = OPENSSL_malloc(num);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mmc: use core clock frequency in bcm2835 sdhost

[Jonathan Gray]

In raspberrypi-firmware 7fdcd00e00a42a1c91e8bd6f5eb8352fe9358557 and
later start.elf now sets the EMMC clock to 200 MHz.

According to Phil Elwell in
https://github.com/raspberrypi/firmware/issues/953
the SDHost controller shares the core/VPU clock and doesn't use
the EMMC clock.

Use the core clock id when determining the frequency to allow
U-Boot to work with recent versions of raspberrypi-firmware.
Otherwise U-Boot hangs at:

U-Boot 2018.03 (Mar 14 2018 - 20:36:00 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT...

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: Alexander Graf <ag...@suse.de>
Cc: Peter Robinson <pbrobin...@gmail.com>
---
 arch/arm/mach-bcm283x/include/mach/msg.h | 3 ++-
 arch/arm/mach-bcm283x/msg.c  | 4 ++--
 drivers/mmc/bcm2835_sdhci.c  | 2 +-
 drivers/mmc/bcm2835_sdhost.c | 3 ++-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-bcm283x/include/mach/msg.h 
b/arch/arm/mach-bcm283x/include/mach/msg.h
index 478b1f1c50..d055480ba1 100644
--- a/arch/arm/mach-bcm283x/include/mach/msg.h
+++ b/arch/arm/mach-bcm283x/include/mach/msg.h
@@ -18,9 +18,10 @@ int bcm2835_power_on_module(u32 module);
 /**
  * bcm2835_get_mmc_clock() - get the frequency of the MMC clock
  *
+ * @clock_id: ID of clock to get frequency for
  * @return clock frequency, or -ve on error
  */
-int bcm2835_get_mmc_clock(void);
+int bcm2835_get_mmc_clock(u32 clock_id);
 
 /**
  * bcm2835_get_video_size() - get the current display size
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 92e93ad9e5..ad29f3be09 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -65,7 +65,7 @@ int bcm2835_power_on_module(u32 module)
return 0;
 }
 
-int bcm2835_get_mmc_clock(void)
+int bcm2835_get_mmc_clock(u32 clock_id)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1);
int ret;
@@ -76,7 +76,7 @@ int bcm2835_get_mmc_clock(void)
 
BCM2835_MBOX_INIT_HDR(msg_clk);
BCM2835_MBOX_INIT_TAG(_clk->get_clock_rate, GET_CLOCK_RATE);
-   msg_clk->get_clock_rate.body.req.clock_id = BCM2835_MBOX_CLOCK_ID_EMMC;
+   msg_clk->get_clock_rate.body.req.clock_id = clock_id;
 
ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, _clk->hdr);
if (ret) {
diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
index 3157354d2a..08bddd410e 100644
--- a/drivers/mmc/bcm2835_sdhci.c
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -183,7 +183,7 @@ static int bcm2835_sdhci_probe(struct udevice *dev)
if (base == FDT_ADDR_T_NONE)
return -EINVAL;
 
-   ret = bcm2835_get_mmc_clock();
+   ret = bcm2835_get_mmc_clock(BCM2835_MBOX_CLOCK_ID_EMMC);
if (ret < 0) {
debug("%s: Failed to set MMC clock (err=%d)\n", __func__, ret);
return ret;
diff --git a/drivers/mmc/bcm2835_sdhost.c b/drivers/mmc/bcm2835_sdhost.c
index 1bf52a3019..bccd182e50 100644
--- a/drivers/mmc/bcm2835_sdhost.c
+++ b/drivers/mmc/bcm2835_sdhost.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -941,7 +942,7 @@ static int bcm2835_probe(struct udevice *dev)
if (!host->ioaddr)
return -ENOMEM;
 
-   host->max_clk = bcm2835_get_mmc_clock();
+   host->max_clk = bcm2835_get_mmc_clock(BCM2835_MBOX_CLOCK_ID_CORE);
 
bcm2835_add_host(host);
 
-- 
2.16.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RPi3 Not autobooting from SD-card. {Scanned}

[Jonathan Gray]

On Tue, Mar 06, 2018 at 02:12:23PM +0100, Alexander Graf wrote:
> On 03/06/2018 01:55 PM, Jonathan Gray wrote:
> > On Mon, Mar 05, 2018 at 06:18:59PM +, Peter Robinson wrote:
> > > > > > Hi!
> > > > > > I'm trying to boot from u-boot on a Raspberry Pi 3. But for some 
> > > > > > reason
> > > > > > it
> > > > > > isn't autobooting on the SD-card.
> > > > > > 
> > > > > > Is it possible to get more debug output on the screen console? I 
> > > > > > don't
> > > > > > have
> > > > > > a serial console at the moment.
> > > > > > The output on the screen is:
> > > > > > 
> > > > > > Net:   No ehternet found.
> > > > > > starting USB...
> > > > > > USB:Core Release 2.80a
> > > > > > scanning bus 0 for devices... 4 USB Devices found
> > > > > >  scanning usb for storage devices... 0 Storage Device(s) 
> > > > > > found
> > > > > > Hit any key to stop autoboot:   0
> > > > > > U-Boot>
> > > > > > 
> > > > > > Shouldn't it mention mmc somewhere in the boot message?
> > > > > > 
> > > > > > The first command I type on the prompt is always failing, it's not
> > > > > > outputting anything. Just a new prompt on the next line. The next
> > > > > > commands i
> > > > > > type in are working. Which seems strange.
> > > > > > I got boot.scr set up right, except graphic settings which are 
> > > > > > wrong. It
> > > > > > is
> > > > > > booting the kernel when I type 'run bootcmd'. But only after I type 
> > > > > > in
> > > > > > another command before it.
> > > > > > It seems like it's not detecting the SD-card (mmc0) until I have 
> > > > > > typed
> > > > > > anything into the prompt.
> > > > > > 
> > > > > > Do I have to set any other env variable for it to autoboot? I would 
> > > > > > have
> > > > > > printed the output of printenv here, but since I don't have a serial
> > > > > > console, retyping everything is very time consuming.
> > > > > > printenv seems to have the right settings. It's basically a full 
> > > > > > console
> > > > > > screen of variables. It just doesn't seem to load them until I type 
> > > > > > in
> > > > > > another command before it.
> > > > > > 
> > > > > > boot_targets=mmc0 usb0 pxe dhcp
> > > > > > Which seems right to me.
> > > > > > 
> > > > > > I compiled the latest u-boot from github.
> > > > > > 
> > > > > > If you need more info please let me know and I'll post it.
> > > > > > 
> > > > > > Hope that anyone can point me in the right direction here. Would 
> > > > > > really
> > > > > > appreciate it.
> > > > > I'm seeing the same issues with 2018.03 rc3.
> > > > > 
> > > > > I'm not sure what the issue is and I've not had time to investigate it
> > > > > further yet, but if you type "boot" and hit enter it should boot,
> > > > > sometimes you actually have to type it twice. It will boot but I'm not
> > > > > sure which bits here have causes this regression.
> > > > 
> > > > I do not see this at all on my RPi3. Maybe it's firmware version 
> > > > dependent?
> > > > Do you happen to have an image that always fails for you?
> > > 2018.03 rc3 with "2018-02-09" firmware (so fairly recent) fails for me.
> > 2018.03 rc4 works fine on rpi_3 here with
> 
> Do you have enable_uart=1 in your config.txt? If you do, it works. If you
> don't, it fails :)

yes, config.txt:

arm_control=0x200
enable_uart=1
device_tree_address=0x100
kernel=u-boot.bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RPi3 Not autobooting from SD-card. {Scanned}

[Jonathan Gray]

On Mon, Mar 05, 2018 at 06:18:59PM +, Peter Robinson wrote:
> >>> Hi!
> >>> I'm trying to boot from u-boot on a Raspberry Pi 3. But for some reason
> >>> it
> >>> isn't autobooting on the SD-card.
> >>>
> >>> Is it possible to get more debug output on the screen console? I don't
> >>> have
> >>> a serial console at the moment.
> >>> The output on the screen is:
> >>>
> >>> Net:   No ehternet found.
> >>> starting USB...
> >>> USB:Core Release 2.80a
> >>> scanning bus 0 for devices... 4 USB Devices found
> >>> scanning usb for storage devices... 0 Storage Device(s) found
> >>> Hit any key to stop autoboot:   0
> >>> U-Boot>
> >>>
> >>> Shouldn't it mention mmc somewhere in the boot message?
> >>>
> >>> The first command I type on the prompt is always failing, it's not
> >>> outputting anything. Just a new prompt on the next line. The next
> >>> commands i
> >>> type in are working. Which seems strange.
> >>> I got boot.scr set up right, except graphic settings which are wrong. It
> >>> is
> >>> booting the kernel when I type 'run bootcmd'. But only after I type in
> >>> another command before it.
> >>> It seems like it's not detecting the SD-card (mmc0) until I have typed
> >>> anything into the prompt.
> >>>
> >>> Do I have to set any other env variable for it to autoboot? I would have
> >>> printed the output of printenv here, but since I don't have a serial
> >>> console, retyping everything is very time consuming.
> >>> printenv seems to have the right settings. It's basically a full console
> >>> screen of variables. It just doesn't seem to load them until I type in
> >>> another command before it.
> >>>
> >>> boot_targets=mmc0 usb0 pxe dhcp
> >>> Which seems right to me.
> >>>
> >>> I compiled the latest u-boot from github.
> >>>
> >>> If you need more info please let me know and I'll post it.
> >>>
> >>> Hope that anyone can point me in the right direction here. Would really
> >>> appreciate it.
> >>
> >> I'm seeing the same issues with 2018.03 rc3.
> >>
> >> I'm not sure what the issue is and I've not had time to investigate it
> >> further yet, but if you type "boot" and hit enter it should boot,
> >> sometimes you actually have to type it twice. It will boot but I'm not
> >> sure which bits here have causes this regression.
> >
> >
> > I do not see this at all on my RPi3. Maybe it's firmware version dependent?
> > Do you happen to have an image that always fails for you?
> 
> 2018.03 rc3 with "2018-02-09" firmware (so fairly recent) fails for me.

2018.03 rc4 works fine on rpi_3 here with

raspberrypi-firmware
20180221 / 9ab68bf218ffc84423a2591658260676d373259a

MD5 (bcm2710-rpi-3-b.dtb) = e5ee32f0c14cd23c327f1615df5d6bb4
MD5 (bootcode.bin) = 17efaf1c1ef89289168d71cdc8194982
MD5 (fixup.dat) = fe33157cedaf8130fa4587341553b26b
MD5 (start.elf) = 9c98e338a47e242f1726c508e60c4cc7

with 'boot_targets=usb0 mmc0 pxe dhcp' as root is on usb.

U-Boot 2018.03-rc4-1-gc06b786faf (Mar 06 2018 - 23:30:47 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT... OK
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
Type: Removable Hard Disk
Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
82812 bytes read in 90 ms (898.4 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk m...@7e202000.blk...
Card did not respond to voltage select!
Scanning disk sd...@7e30.blk...
Disk sd...@7e30.blk not ready
Scanning disk usb_mass_storage.lun0...
Found 6 disks
>> OpenBSD/arm64 BOOTAA64 0.11
boot> 
booting sd0a:/bsd: 3990100+592528+580128+806208 
[282379+96+463896+246895]=0x845298
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [ANN] U-Boot v2018.03-rc4 released

[Jonathan Gray]

On Tue, Mar 06, 2018 at 11:36:37AM +, Peter Robinson wrote:
> On Tue, Mar 6, 2018 at 1:28 AM, Tom Rini  wrote:
> > Hey all,
> >
> > It's release day and I've released v2018.03-rc4.  I've included a few
> > different regression fixes I've seen along with some fixes and cleanups.
> > I would like to do the release on March 12th, and likely will so long as
> > no big regressions show up.  I am worried about the RPi3 issue I've seen
> > reported.  Are there any other issues people know of currently?
> >
> > And to repeat myself again, boards and SoC families, etc, that have been
> > orphaned for more than a year should probably get dropped.  I've
> > contacted a few people off-list (which is why we've had a few pickups of
> > late) for things, but if you know someone that would be interested in
> > something, please speak up.
> 
> Just a heads up that I've seen a regression in building i.MX6
> platforms from rc3 with this:
> 
> /builddir/build/BUILD/u-boot-2018.03-rc4/arch/arm/mach-imx/spl.c:160:5:
> error: redefinition of 'spl_boot_mode'
>  u32 spl_boot_mode(const u32 boot_device)
>  ^
> /builddir/build/BUILD/u-boot-2018.03-rc4/arch/arm/mach-imx/spl.c:137:5:
> note: previous definition of 'spl_boot_mode' was here
>  u32 spl_boot_mode(const u32 boot_device)
>  ^
> make[3]: *** 
> [/builddir/build/BUILD/u-boot-2018.03-rc4/scripts/Makefile.build:280:
> spl/arch/arm/mach-imx/spl.o] Error 1
> make[2]: *** 
> [/builddir/build/BUILD/u-boot-2018.03-rc4/scripts/Makefile.spl:351:
> spl/arch/arm/mach-imx] Error 2
> make[2]: *** Waiting for unfinished jobs
> 
> I've not had time to dig further just yet, just wanted to give people
> a heads up.

mx6cuboxi builds/runs fine here with
5e62f828256d66e2b28def4f9ef20a2a05c2d04f/v2018.03-rc4
and linaro gcc 6.3-2017.02
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] tools/kwbimage: fix LibreSSL build

[Jonathan Gray]

Fix build after addition of RSA_get0_key() to LibreSSL.
Patch from Theo Buehler and Stuart Henderson.

Signed-off-by: Theo Buehler 
Signed-off-by: Stuart Henderson 
---
 tools/kwbimage.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index ccecf87185..3ca3b3b4a6 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -24,7 +24,8 @@
 #include 
 #include 
 
-#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x207fL)
 static void RSA_get0_key(const RSA *r,
  const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
 {
@@ -36,7 +37,7 @@ static void RSA_get0_key(const RSA *r,
*d = r->d;
 }
 
-#else
+#elif !defined(LIBRESSL_VERSION_NUMBER)
 void EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx)
 {
EVP_MD_CTX_reset(ctx);
-- 
2.16.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH 2/2] net: designware: add clock support

[Jonathan Gray]

Thanks, that fixes it.  Hopefully it makes 2018.03.

On Fri, Feb 16, 2018 at 08:02:17AM +, Patrice CHOTARD wrote:
> Hi Jonathan
> 
> Have you tried to apply the fix available here ?
> 
> http://u-boot.10912.n7.nabble.com/PATCH-NET-designware-fix-clock-enable-td320043.html
> 
> Regards
> 
> Patrice
> 
> 
> On 02/16/2018 08:17 AM, Jonathan Gray wrote:
> > On Wed, Nov 29, 2017 at 09:06:11AM +0100, patrice.chot...@st.com wrote:
> >> From: Patrice Chotard <patrice.chot...@st.com>
> >>
> >> This implementation manages several clocks, disable and
> >> free all of them in case of error during probe and in remove
> >> callback.
> >>
> >> Signed-off-by: Patrice Chotard <patrice.chot...@st.com>
> >> ---
> >>   drivers/net/designware.c | 43 +++
> >>   drivers/net/designware.h |  4 
> >>   2 files changed, 47 insertions(+)
> > 
> > RK3288 Ethernet on the ASUS Tinker Board fails to probe with master
> > (32fe36574ea5e6ea55313e16547b98a984af7767) but worked with 2018.01.
> > 
> > ba1f966725223c605ed504b09446c52a3f201c2b is the first bad commit
> > commit ba1f966725223c605ed504b09446c52a3f201c2b
> > Author: Patrice Chotard <patrice.chot...@st.com>
> > Date:   Wed Nov 29 09:06:11 2017 +0100
> > 
> >  net: designware: add clock support
> >  
> >  This implementation manages several clocks, disable and
> >  free all of them in case of error during probe and in remove
> >  callback.
> >  
> >  Signed-off-by: Patrice Chotard <patrice.chot...@st.com>
> >  Reviewed-by: Simon Glass <s...@chromium.org>
> >  Acked-by: Joe Hershberger <joe.hershber...@ni.com>
> > 
> > :04 04 6f1002af4c0f3ed7ab6f2418d4f2de00bbe454a7 
> > e18d2a6c24cbfd055c89fa250946bf85199fff90 M  drivers
> > 
> > U-Boot 2018.03-rc2-00047-gc1531533c5 (Feb 16 2018 - 15:38:39 +1100)
> > 
> > Model: Tinker-RK3288
> > DRAM:  2 GiB
> > MMC:   dwmmc@ff0c: 1
> > Loading Environment from MMC... *** Warning - bad CRC, using default 
> > environment
> > 
> > Failed (-5)
> > In:serial
> > Out:   serial
> > Err:   serial
> > Model: Tinker-RK3288
> > Net:   failed to enable clock 0
> > No ethernet found.
> > Hit any key to stop autoboot:  0
> > => dm tree
> >   Class Probed  Driver  Name
> > 
> >   root  [ + ]   root_drive  root_driver
> >   clk   [   ]   fixed_rate  |-- oscillator
> >   mmc   [ + ]   rockchip_r  |-- dwmmc@ff0c
> >   blk   [ + ]   mmc_blk |   `-- dw...@ff0c.blk
> >   adc   [ + ]   rockchip_s  |-- saradc@ff10
> >   i2c   [   ]   i2c_rockch  |-- i2c@ff17
> >   serial[   ]   ns16550_se  |-- serial@ff18
> >   serial[   ]   ns16550_se  |-- serial@ff19
> >   serial[ + ]   ns16550_se  |-- serial@ff69
> >   serial[   ]   ns16550_se  |-- serial@ff1b
> >   serial[   ]   ns16550_se  |-- serial@ff1c
> >   eth   [   ]   gmac_rockc  |-- ethernet@ff29
> >   usb   [   ]   dwc2_usb|-- usb@ff54
> >   usb   [   ]   dwc2_usb|-- usb@ff58
> >   ram   [   ]   rockchip_r  |-- dmc@ff61
> >   i2c   [ + ]   i2c_rockch  |-- i2c@ff65
> >   pmic  [ + ]   rk8xx pmic  |   `-- pmic@1b
> >   regulator  [  ]   rk8xx_buck  |   |-- DCDC_REG1
> >   regulator  [  ]   rk8xx_buck  |   |-- DCDC_REG2
> >   regulator  [  ]   rk8xx_buck  |   |-- DCDC_REG3
> >   regulator  [  ]   rk8xx_buck  |   |-- DCDC_REG4
> >   regulator  [  ]   rk8xx_ldo   |   |-- LDO_REG1
> >   regulator  [  ]   rk8xx_ldo   |   |-- LDO_REG2
> >   regulator  [  ]   rk8xx_ldo   |   |-- LDO_REG3
> >   regulator  [  ]   rk8xx_ldo   |   |-- LDO_REG4
> >   regulator  [ + ]   rk8xx_ldo  |   |-- LDO_REG5
> >   regulator  [  ]   rk8xx_ldo   |   |-- LDO_REG6
> >   regulator  [  ]   rk8xx_ldo   |   |-- LDO_REG7
> >   regulator  [  ]   rk8xx_ldo   |   |-- LDO_REG8
> >   regulator  [  ]   rk8xx_swit  |   |-- SWITCH_REG1
> >   regulator  [  ]   rk8xx_swit  |   `-- SWITCH_REG2
> >   i2c   [ + ]   i2c_rockch  |-- i2c@ff66
> >   i2c_eeprom [ + ]   i2c_eeprom |   `-- m24c08@50
> >   pwm   [   ]   rk_pwm  |-- pwm@ff68
> >   pwm 

Re: [U-Boot] [RESEND PATCH 2/2] net: designware: add clock support

[Jonathan Gray]

On Wed, Nov 29, 2017 at 09:06:11AM +0100, patrice.chot...@st.com wrote:
> From: Patrice Chotard 
> 
> This implementation manages several clocks, disable and
> free all of them in case of error during probe and in remove
> callback.
> 
> Signed-off-by: Patrice Chotard 
> ---
>  drivers/net/designware.c | 43 +++
>  drivers/net/designware.h |  4 
>  2 files changed, 47 insertions(+)

RK3288 Ethernet on the ASUS Tinker Board fails to probe with master
(32fe36574ea5e6ea55313e16547b98a984af7767) but worked with 2018.01.

ba1f966725223c605ed504b09446c52a3f201c2b is the first bad commit
commit ba1f966725223c605ed504b09446c52a3f201c2b
Author: Patrice Chotard 
Date:   Wed Nov 29 09:06:11 2017 +0100

net: designware: add clock support

This implementation manages several clocks, disable and
free all of them in case of error during probe and in remove
callback.

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
Acked-by: Joe Hershberger 

:04 04 6f1002af4c0f3ed7ab6f2418d4f2de00bbe454a7 
e18d2a6c24cbfd055c89fa250946bf85199fff90 M  drivers

U-Boot 2018.03-rc2-00047-gc1531533c5 (Feb 16 2018 - 15:38:39 +1100)

Model: Tinker-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed (-5)
In:serial
Out:   serial
Err:   serial
Model: Tinker-RK3288
Net:   failed to enable clock 0
No ethernet found.
Hit any key to stop autoboot:  0
=> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 clk[   ]   fixed_rate  |-- oscillator
 mmc[ + ]   rockchip_r  |-- dwmmc@ff0c
 blk[ + ]   mmc_blk |   `-- dw...@ff0c.blk
 adc[ + ]   rockchip_s  |-- saradc@ff10
 i2c[   ]   i2c_rockch  |-- i2c@ff17
 serial [   ]   ns16550_se  |-- serial@ff18
 serial [   ]   ns16550_se  |-- serial@ff19
 serial [ + ]   ns16550_se  |-- serial@ff69
 serial [   ]   ns16550_se  |-- serial@ff1b
 serial [   ]   ns16550_se  |-- serial@ff1c
 eth[   ]   gmac_rockc  |-- ethernet@ff29
 usb[   ]   dwc2_usb|-- usb@ff54
 usb[   ]   dwc2_usb|-- usb@ff58
 ram[   ]   rockchip_r  |-- dmc@ff61
 i2c[ + ]   i2c_rockch  |-- i2c@ff65
 pmic   [ + ]   rk8xx pmic  |   `-- pmic@1b
 regulator  [   ]   rk8xx_buck  |   |-- DCDC_REG1
 regulator  [   ]   rk8xx_buck  |   |-- DCDC_REG2
 regulator  [   ]   rk8xx_buck  |   |-- DCDC_REG3
 regulator  [   ]   rk8xx_buck  |   |-- DCDC_REG4
 regulator  [   ]   rk8xx_ldo   |   |-- LDO_REG1
 regulator  [   ]   rk8xx_ldo   |   |-- LDO_REG2
 regulator  [   ]   rk8xx_ldo   |   |-- LDO_REG3
 regulator  [   ]   rk8xx_ldo   |   |-- LDO_REG4
 regulator  [ + ]   rk8xx_ldo   |   |-- LDO_REG5
 regulator  [   ]   rk8xx_ldo   |   |-- LDO_REG6
 regulator  [   ]   rk8xx_ldo   |   |-- LDO_REG7
 regulator  [   ]   rk8xx_ldo   |   |-- LDO_REG8
 regulator  [   ]   rk8xx_swit  |   |-- SWITCH_REG1
 regulator  [   ]   rk8xx_swit  |   `-- SWITCH_REG2
 i2c[ + ]   i2c_rockch  |-- i2c@ff66
 i2c_eeprom [ + ]   i2c_eeprom  |   `-- m24c08@50
 pwm[   ]   rk_pwm  |-- pwm@ff68
 pwm[   ]   rk_pwm  |-- pwm@ff680010
 syscon [ + ]   rk3288_sys  |-- power-management@ff73
 syscon [   ]   rk3288_sys  |-- syscon@ff74
 clk[ + ]   rockchip_r  |-- clock-controller@ff76
 sysreset   [   ]   rockchip_s  |   `-- sysreset
 syscon [ + ]   rk3288_sys  |-- syscon@ff77
 syscon [   ]   rk3288_sys  |-- syscon@ffac
 pinctrl[ + ]   rockchip_r  |-- pinctrl
 gpio   [   ]   gpio_rockc  |   |-- gpio0@ff75
 gpio   [   ]   gpio_rockc  |   |-- gpio1@ff78
 gpio   [   ]   gpio_rockc  |   |-- gpio2@ff79
 gpio   [   ]   gpio_rockc  |   |-- gpio3@ff7a
 gpio   [ + ]   gpio_rockc  |   |-- gpio4@ff7b
 gpio   [   ]   gpio_rockc  |   |-- gpio5@ff7c
 gpio   [   ]   gpio_rockc  |   |-- gpio6@ff7d
 gpio   [ + ]   gpio_rockc  |   |-- gpio7@ff7e
 gpio   [   ]   gpio_rockc  |   |-- gpio8@ff7f
 pinconfig  [   ]   pinconfig   |   |-- pcfg-pull-up
 pinconfig  [   ]   pinconfig   |   |-- pcfg-pull-down
 pinconfig  [   ]   pinconfig   |   |-- pcfg-pull-none
 pinconfig  [   ]   pinconfig   |   |-- pcfg-pull-none-12ma
 pinconfig  [ + ]   pinconfig   |   |-- sleep
 pinconfig  [ + ]   pinconfig   |   |   |-- global-pwroff
 pinconfig  [   ]   pinconfig   |   |   |-- ddrio-pwroff
 pinconfig  [   ]   pinconfig   |   |   |-- ddr0-retention
 pinconfig  [   ]   pinconfig   |   |   `-- ddr1-retention
 pinconfig  [ + ]   pinconfig   |   |-- i2c0
 pinconfig  [ + ]   pinconfig   | 

Re: [U-Boot] Please fix ls1046ardb

[Jonathan Gray]

On Wed, Feb 14, 2018 at 07:25:53PM +, York Sun wrote:
> Mingkai,
> 
> LS1046ARDB is broken for both QSPI and SD. For QSPI, I cannot use
> environmental variables. For SD boot, it fails when trying to init SD
> card. Partial log is
> 
> Initializing DDRusing SPD
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> Trying to boot from MMC1
> unable to select a mode
> mmc_init: -524, time 51
> spl: mmc init failed with error: -524
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 
> Please investigate.
> 
> York

This reminds me of the problem I ran into with qemu vexpress-a15.
https://lists.denx.de/pipermail/u-boot/2018-February/319965.html
https://patchwork.ozlabs.org/patch/871324/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] spl: eMMC/SD: Provide one __weak spl_boot_mode() function

[Jonathan Gray]

On Sat, Feb 10, 2018 at 10:57:26AM +0100, Lukasz Majewski wrote:
> Hi Jonathan,
> 
> > On Sat, Feb 10, 2018 at 01:45:16AM +0100, Lukasz Majewski wrote:
> > > Hi Jonathan,
> > >   
> > > > On Sat, Feb 03, 2018 at 11:00:35AM -0200, Fabio Estevam wrote:  
> > > > > On Sat, Feb 3, 2018 at 5:29 AM, Lukasz Majewski 
> > > > > wrote:
> > > > > > The goal of this patch is to clean up the code related to
> > > > > > choosing SPL MMC boot mode.
> > > > > >
> > > > > > The spl_boot_mode() now is called only in spl_mmc_load_image()
> > > > > > function, which is only compiled in if CONFIG_SPL_MMC_SUPPORT
> > > > > > is enabled.
> > > > > >
> > > > > > To achieve the goal, all per mach/arch implementations
> > > > > > eligible for unification has been replaced with one __weak
> > > > > > implementation.
> > > > > >
> > > > > > Signed-off-by: Lukasz Majewski 
> > > > > > Reviewed-by: Marek Vasut 
> > > > > > Reviewed-by: Stefano Babic 
> > > > > > Acked-by: Michal Simek  (For
> > > > > > ZynqMP)
> > > > > 
> > > > > Nice cleanup:
> > > > > 
> > > > > Reviewed-by: Fabio Estevam 
> > > > 
> > > > This has broken booting via mmc with mx6cuboxi for me.
> > > > 
> > > > SPL loops on
> > > > 
> > > > U-Boot SPL 2018.03-rc1-00212-g48914fc119 (Feb 10 2018 - 11:04:33
> > > > +1300) Trying to boot from MMC1
> > > > Failed to mount ext2 filesystem...
> > > > spl_load_image_ext: ext4fs mount err - 0  
> > > 
> > > Could you check what is the status of following defines in
> > > your .config file:
> > > 
> > > CONFIG_SPL_FAT_SUPPORT
> > > CONFIG_SUPPORT_EMMC_BOOT  
> > 
> > "# CONFIG_SPL_FAT_SUPPORT is not set"
> > 
> > CONFIG_SUPPORT_EMMC_BOOT is not in the .config at all
> > 
> > CONFIG_SPL_EXT_SUPPORT previously for imx6 would result in
> > MMCSD_MODE_RAW but now it results in MMCSD_MODE_FS.
> > 
> > > 
> > > And if by any chance your don't have:
> > > CONFIG_SPL_EXT_SUPPORT defined?  
> > 
> > CONFIG_SPL_EXT_SUPPORT=y
> 
> Could you for test comment out the above define?

Removing CONFIG_SPL_EXT_SUPPORT=y from the defconfig or using the
following diff makes the system boot.

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 351f4edd41..1541a4837d 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -283,7 +283,7 @@ static int spl_mmc_do_fs_boot(struct spl_image_info 
*spl_image, struct mmc *mmc)
 
 u32 __weak spl_boot_mode(const u32 boot_device)
 {
-#if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
+#if defined(CONFIG_SPL_FAT_SUPPORT)
return MMCSD_MODE_FS;
 #elif defined(CONFIG_SUPPORT_EMMC_BOOT)
return MMCSD_MODE_EMMCBOOT;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] spl: eMMC/SD: Provide one __weak spl_boot_mode() function

[Jonathan Gray]

On Sat, Feb 10, 2018 at 01:45:16AM +0100, Lukasz Majewski wrote:
> Hi Jonathan,
> 
> > On Sat, Feb 03, 2018 at 11:00:35AM -0200, Fabio Estevam wrote:
> > > On Sat, Feb 3, 2018 at 5:29 AM, Lukasz Majewski 
> > > wrote:  
> > > > The goal of this patch is to clean up the code related to
> > > > choosing SPL MMC boot mode.
> > > >
> > > > The spl_boot_mode() now is called only in spl_mmc_load_image()
> > > > function, which is only compiled in if CONFIG_SPL_MMC_SUPPORT is
> > > > enabled.
> > > >
> > > > To achieve the goal, all per mach/arch implementations eligible
> > > > for unification has been replaced with one __weak implementation.
> > > >
> > > > Signed-off-by: Lukasz Majewski 
> > > > Reviewed-by: Marek Vasut 
> > > > Reviewed-by: Stefano Babic 
> > > > Acked-by: Michal Simek  (For ZynqMP)  
> > > 
> > > Nice cleanup:
> > > 
> > > Reviewed-by: Fabio Estevam   
> > 
> > This has broken booting via mmc with mx6cuboxi for me.
> > 
> > SPL loops on
> > 
> > U-Boot SPL 2018.03-rc1-00212-g48914fc119 (Feb 10 2018 - 11:04:33
> > +1300) Trying to boot from MMC1
> > Failed to mount ext2 filesystem...
> > spl_load_image_ext: ext4fs mount err - 0
> 
> Could you check what is the status of following defines in your .config
> file:
> 
> CONFIG_SPL_FAT_SUPPORT
> CONFIG_SUPPORT_EMMC_BOOT

"# CONFIG_SPL_FAT_SUPPORT is not set"

CONFIG_SUPPORT_EMMC_BOOT is not in the .config at all

CONFIG_SPL_EXT_SUPPORT previously for imx6 would result in
MMCSD_MODE_RAW but now it results in MMCSD_MODE_FS.

> 
> And if by any chance your don't have:
> CONFIG_SPL_EXT_SUPPORT defined?

CONFIG_SPL_EXT_SUPPORT=y
CONFIG_SPL_MMC_SUPPORT=y

mx6cuboxi_defconfig with no changes

> 
> From what you have written above I assume that you boot from the
> same medium - i.e. eMMC (so SPL and u-boot.img are on the same medium) ?

Both SPL and u-boot.img are on a microsd card.

The set CONFIG_SPL_* in .config are

CONFIG_SPL_SYS_THUMB_BUILD=y
CONFIG_SPL_USE_ARCH_MEMCPY=y
CONFIG_SPL_USE_ARCH_MEMSET=y
CONFIG_SPL_LDSCRIPT="arch/arm/mach-omap2/u-boot-spl.lds"
CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_SPL_MMC_SUPPORT=y
CONFIG_SPL_SERIAL_SUPPORT=y
CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_SPL_WATCHDOG_SUPPORT=y
CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=5
CONFIG_SPL_LOGLEVEL=4
CONFIG_SPL=y
CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
CONFIG_SPL_EXT_SUPPORT=y
CONFIG_SPL_I2C_SUPPORT=y
CONFIG_SPL_DOS_PARTITION=y
CONFIG_SPL_ISO_PARTITION=y
CONFIG_SPL_EFI_PARTITION=y
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] spl: eMMC/SD: Provide one __weak spl_boot_mode() function

[Jonathan Gray]

On Sat, Feb 03, 2018 at 11:00:35AM -0200, Fabio Estevam wrote:
> On Sat, Feb 3, 2018 at 5:29 AM, Lukasz Majewski  wrote:
> > The goal of this patch is to clean up the code related to choosing SPL
> > MMC boot mode.
> >
> > The spl_boot_mode() now is called only in spl_mmc_load_image() function,
> > which is only compiled in if CONFIG_SPL_MMC_SUPPORT is enabled.
> >
> > To achieve the goal, all per mach/arch implementations eligible for
> > unification has been replaced with one __weak implementation.
> >
> > Signed-off-by: Lukasz Majewski 
> > Reviewed-by: Marek Vasut 
> > Reviewed-by: Stefano Babic 
> > Acked-by: Michal Simek  (For ZynqMP)
> 
> Nice cleanup:
> 
> Reviewed-by: Fabio Estevam 

This has broken booting via mmc with mx6cuboxi for me.

SPL loops on

U-Boot SPL 2018.03-rc1-00212-g48914fc119 (Feb 10 2018 - 11:04:33 +1300)
Trying to boot from MMC1
Failed to mount ext2 filesystem...
spl_load_image_ext: ext4fs mount err - 0

There is no ext2/ext3/ext4 fs, next U-Boot stage is raw, ie

dd if=mx6cuboxi/SPL of=/dev/sd2c bs=1024 seek=1
dd if=mx6cuboxi/u-boot.img of=/dev/sd2c bs=1024 seek=69

=> part list mmc 0

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 204832768   -01 0c Boot
  4 34816   15642624-04 a6

With this commit reverted:

U-Boot SPL 2018.03-rc1-00214-ge3f2485203 (Feb 10 2018 - 12:38:46 +1300)
Trying to boot from MMC1


U-Boot 2018.03-rc1-00214-ge3f2485203 (Feb 10 2018 - 12:38:46 +1300)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 27C
Reset cause: POR
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... OK
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
37503 bytes read in 18 ms (2 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Disk usb0 not ready
Disk usb1 not ready
Disk usb2 not ready
Disk usb3 not ready
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Scanning disks on sata...
Disk sata0 not ready
Found 3 disks
76528 bytes read in 30 ms (2.4 MiB/s)
## Starting EFI application at 1200 ...
>> OpenBSD/armv7 BOOTARM 1.0
boot> 
booting sd0a:/bsd: 4531856+203028+560156 [277405+90+281904+244582]=0x5d6b88
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Sat, Feb 03, 2018 at 12:47:48PM +1100, Jonathan Gray wrote:
> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> > On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> > 
> > > The bcm283x family of SoCs have a GPIO controller that also acts as
> > > pinctrl controller.
> > > 
> > > This patch introduces a new pinctrl driver that can actually properly mux
> > > devices into their device tree defined pin states and is now the primary
> > > owner of the gpio device. The previous GPIO driver gets moved into a
> > > subdevice of the pinctrl driver, bound to the same OF node.
> > > 
> > > That way whenever a device asks for pinctrl support, it gets it
> > > automatically from the pinctrl driver and GPIO support is still available
> > > in the normal command line phase.
> > > 
> > > Signed-off-by: Alexander Graf <ag...@suse.de>
> > 
> > Applied to u-boot/master, thanks!
> 
> It seems one of the recent commits here has broken booting on rpi_3 with
> the vendor supplied device tree via efi_loader.
> 
> last working commit seems to be:
> 
> 8996975ff8422e07f43eb8b3b0c7ed8c2b35442f
> powerpc: Drop CONFIG_WALNUT and other related dead code
> 
> After that were
> 
> caf2233b281c03e3e359061a3dfa537d8a25c273
> bcm283x: Add pinctrl driver
> 
> c8a73a26d6dd9b7d489e66529fe1412425d8f2d1
> mmc: Add bcm2835 sdhost controller
> 
> These can't easily be reverted due to other changes.

This turns out to have been efi loader changes, and is resolved
by 'efi_loader: correct efi_disk_register'
https://lists.denx.de/pipermail/u-boot/2018-February/320043.html

Still not clear on why git bisect kept pointing at these pinctrl changes
on rpi_3.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/2] mmc: Fix bug in sd_set_card_speed()

[Jonathan Gray]

On Fri, Feb 09, 2018 at 12:09:27PM +0100, Jean-Jacques Hiblot wrote:
> After settings the speed of the sd with the switch command, a check is
> done to make sure that the new speed has been set. The current check has a
> masking error: speed are encoded on 4 bits only.
> Fix it by masking the upper bits.
> 
> This fixes a problem seen with QEmu emulating a vexpress-a15.
> 
> Reported-by: Jonathan Gray <j...@jsg.id.au>
> Signed-off-by: Jean-Jacques Hiblot <jjhib...@ti.com>

With this change the emulated mmc controller can be accessed again here.

Tested-by: Jonathan Gray <j...@jsg.id.au>

> 
> ---
> 
>  drivers/mmc/mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 255310a..31614dd 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1333,7 +1333,7 @@ static int sd_set_card_speed(struct mmc *mmc, enum 
> bus_mode mode)
>   if (err)
>   return err;
>  
> - if ((__be32_to_cpu(switch_status[4]) >> 24) != speed)
> + if (((__be32_to_cpu(switch_status[4]) >> 24) & 0xF) != speed)
>   return -ENOTSUPP;
>  
>   return 0;
> -- 
> 1.9.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] efi_loader: correct efi_disk_register

[Jonathan Gray]

On Fri, Feb 09, 2018 at 08:55:47PM +0100, Heinrich Schuchardt wrote:
> efi_disk_register should return as status code (efi_status_t).
> 
> Disks with zero blocks should be reported as 'not ready' without throwing
> an error.
> 
> This patch solves a problem running OpenBSD on system configured with
> CONFIG_BLK=n (e.g. i.MX6).
> 
> Reported-by: Jonathan Gray <j...@jsg.id.au>
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>

Thanks, this change resolves the problems I was seeing with
master as of e24bd1e79e223aa89854c0be95a53e2d538144a5 on
both mx6cuboxi and rpi_3.

Tested-by: Jonathan Gray <j...@jsg.id.au>

> ---
> v2
>   remove superfluous check
> ---
>  include/efi_loader.h  |  2 +-
>  lib/efi_loader/efi_disk.c | 71 
> +--
>  2 files changed, 45 insertions(+), 28 deletions(-)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index a2d82e1db73..07730c3f394 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -173,7 +173,7 @@ extern struct list_head efi_obj_list;
>  /* Called by bootefi to make console interface available */
>  int efi_console_register(void);
>  /* Called by bootefi to make all disk storage accessible as EFI objects */
> -int efi_disk_register(void);
> +efi_status_t efi_disk_register(void);
>  /* Create handles and protocols for the partitions of a block device */
>  int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
>  const char *if_typename, int diskid,
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index ac39a65ee89..825a6d86de8 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -226,25 +226,26 @@ efi_fs_from_path(struct efi_device_path *full_path)
>   * @offset   offset into disk for simple partitions
>   * @return   disk object
>   */
> -static struct efi_disk_obj *efi_disk_add_dev(
> +static efi_status_t efi_disk_add_dev(
>   efi_handle_t parent,
>   struct efi_device_path *dp_parent,
>   const char *if_typename,
>   struct blk_desc *desc,
>   int dev_index,
>   lbaint_t offset,
> - unsigned int part)
> + unsigned int part,
> + struct efi_disk_obj **disk)
>  {
>   struct efi_disk_obj *diskobj;
>   efi_status_t ret;
>  
>   /* Don't add empty devices */
>   if (!desc->lba)
> - return NULL;
> + return EFI_NOT_READY;
>  
>   diskobj = calloc(1, sizeof(*diskobj));
>   if (!diskobj)
> - goto out_of_memory;
> + return EFI_OUT_OF_RESOURCES;
>  
>   /* Hook up to the device list */
>   efi_add_handle(>parent);
> @@ -262,11 +263,11 @@ static struct efi_disk_obj *efi_disk_add_dev(
>   ret = efi_add_protocol(diskobj->parent.handle, _block_io_guid,
>  >ops);
>   if (ret != EFI_SUCCESS)
> - goto out_of_memory;
> + return ret;
>   ret = efi_add_protocol(diskobj->parent.handle, _guid_device_path,
>  diskobj->dp);
>   if (ret != EFI_SUCCESS)
> - goto out_of_memory;
> + return ret;
>   if (part >= 1) {
>   diskobj->volume = efi_simple_file_system(desc, part,
>diskobj->dp);
> @@ -274,7 +275,7 @@ static struct efi_disk_obj *efi_disk_add_dev(
>  _simple_file_system_protocol_guid,
>  diskobj->volume);
>   if (ret != EFI_SUCCESS)
> - goto out_of_memory;
> + return ret;
>   }
>   diskobj->ops = block_io_disk_template;
>   diskobj->ifname = if_typename;
> @@ -291,10 +292,9 @@ static struct efi_disk_obj *efi_disk_add_dev(
>   if (part != 0)
>   diskobj->media.logical_partition = 1;
>   diskobj->ops.media = >media;
> - return diskobj;
> -out_of_memory:
> - printf("ERROR: Out of memory\n");
> - return NULL;
> + if (disk)
> + *disk = diskobj;
> + return EFI_SUCCESS;
>  }
>  
>  /*
> @@ -330,8 +330,12 @@ int efi_disk_create_partitions(efi_handle_t parent, 
> struct blk_desc *desc,
>   continue;
>   snprintf(devname, sizeof(devname), "%s:%d", pdevname,
>

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Fri, Feb 09, 2018 at 04:43:09AM +0100, Heinrich Schuchardt wrote:
> On 02/09/2018 12:55 AM, Jonathan Gray wrote:
> > On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
> > > On 02/08/2018 10:49 AM, Jonathan Gray wrote:
> > > > On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
> > > > > On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> > > > > > 
> > > > > > 
> > > > > > > Am 08.02.2018 um 06:49 schrieb Jonathan Gray <j...@jsg.id.au>:
> > > > > > > 
> > > > > > > On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> > > > > > > > > Date: Mon, 5 Feb 2018 21:06:59 +1100
> > > > > > > > > From: Jonathan Gray <j...@jsg.id.au>
> > > > > > > > > 
> > > > > > > > > > > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > > > > > > > > > > failed(6). will try /bsd
> > > > > > > > > > 
> > > > > > > > > > How do you find out that it's sd0a instead of sd1a?
> > > > > > > > > 
> > > > > > > > > The loaded image protocol I believe.
> > > > > > > > 
> > > > > > > > Actually the OpenBSD bootloader currently only supports loading 
> > > > > > > > the
> > > > > > > > bsd kernel from the same device as the bootloader.  It will 
> > > > > > > > always
> > > > > > > > call that device sd0.  It invokes the device path protocol on 
> > > > > > > > the
> > > > > > > > loaded image handle and then matches that path to a device that
> > > > > > > > supports the block io protocol.
> > > > > > > 
> > > > > > > Perhaps the problem is elsewhere as U-Boot master also broke
> > > > > > > vexpress_ca15_tc2 and mx6cuboxi targets:
> > > > > > 
> > > > > > Perfect, so can you quickly bisect it now that the bisect doesn???t 
> > > > > > end at the pinctrl driver?
> > > > > 
> > > > > On cubox a bisect points to
> > > > > 
> > > > > commit 64e4db0f119151a1345e1da19d152eda550394e7
> > > > > Author: Heinrich Schuchardt <xypron.g...@gmx.de>
> > > > > Date:   Fri Jan 19 20:24:47 2018 +0100
> > > > > 
> > > > >  efi_loader: make efi_disk_create_partitions a global symbol
> > > > >  Up to now we have been using efi_disk_create_partitions() to 
> > > > > create
> > > > >  partitions for block devices that existed before starting an EFI
> > > > >  application.
> > > > >  We need to call it for block devices created by EFI
> > > > >  applications at run time. The EFI application will define the
> > > > >  handle for the block device and install a device path protocol
> > > > >  on it. We have to use this device path as stem for the partition
> > > > >  device paths.
> > > > >  Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> > > > >  Signed-off-by: Alexander Graf <ag...@suse.de>
> > > > > 
> > > > >   include/efi_loader.h  |  4 +++
> > > > >   lib/efi_loader/efi_disk.c | 84 
> > > > > +++
> > > > >   2 files changed, 64 insertions(+), 24 deletions(-)
> > > > > 
> > > > > If I revert this commit a image built from master works.
> > > > 
> > > > Actually master doesn't build with just that reverted, seems I had stale
> > > > object files.
> > > 
> > > When bisecting running
> > > 'make mrproper && make foo_defconfig && make'
> > > in each round is recommendable.
> > > 
> > > Do you still assume a problem that requires a change in U-Boot?
> > > Or can we close the topic?
> > > 
> > > Best regards
> > > 
> > > Heinrich
> > 
> > There are multiple regressions with U-Boot master compared to 2018.01.
> 
> U-Boot master is a moving target. Please, state the commit.

The commit was mentioned three times in the mail but you seem
to have missed that.

again e24bd1e79e223aa89854c0

Re: [U-Boot] [PATCH v3 11/18] efi_loader: make efi_disk_create_partitions a global symbol

[Jonathan Gray]

On Fri, Jan 19, 2018 at 08:24:47PM +0100, Heinrich Schuchardt wrote:
> Up to now we have been using efi_disk_create_partitions() to create
> partitions for block devices that existed before starting an EFI
> application.
> 
> We need to call it for block devices created by EFI
> applications at run time. The EFI application will define the
> handle for the block device and install a device path protocol
> on it. We have to use this device path as stem for the partition
> device paths.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v3
>   fix typos in comments
> v2
>   no change

breakage on mx6cuboxi with OpenBSD bootarm.efi, bisects to

commit 64e4db0f119151a1345e1da19d152eda550394e7
Author: Heinrich Schuchardt 
AuthorDate: Fri Jan 19 20:24:47 2018 +0100
Commit: Alexander Graf 
CommitDate: Mon Jan 22 23:09:14 2018 +0100

efi_loader: make efi_disk_create_partitions a global symbol

Up to now we have been using efi_disk_create_partitions() to create
partitions for block devices that existed before starting an EFI
application.

We need to call it for block devices created by EFI
applications at run time. The EFI application will define the
handle for the block device and install a device path protocol
on it. We have to use this device path as stem for the partition
device paths.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf 

with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5

U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
Trying to boot from MMC1


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 24C
Reset cause: POR
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... OK
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
37503 bytes read in 17 ms (2.1 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
76528 bytes read in 31 ms (2.4 MiB/s)
## Starting EFI application at 1200 ...
BS->LocateHandle() returns -2147483634
undefined instruction
pc : [<8e560348>]  lr : [<8e56444c>]
reloc pc : [<15de4348>]lr : [<15de844c>]
sp : 8f57af10  ip : 8ffc2474 fp : 8f57af1c
r10: b000  r9 : 8f57bee0 r8 : 000b
r7 : 8ffa1a9d  r6 : 8ffa16ad r5 : 8e56f0d0  r4 : 8e56e88a
r3 : 8e56dac8  r2 : 0001 r1 :   r0 : 
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

(undefined instruction is used to reset as efi reset was not
present in earlier U-Boot versions).
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/26] mmc: refactor SD startup to make it easier to support new modes

[Jonathan Gray]

On Thu, Sep 21, 2017 at 04:29:57PM +0200, Jean-Jacques Hiblot wrote:
> The SDcard startup process currently handles only 2 modes. To make it
> easier to add support for more modes, let's make the process more generic
> and use a list of the modes to try.
> The major functional change is that when a mode fails we try the next one.
> Not all modes are tried, only those supported by the card and the host.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Simon Glass 

This change broke mmc with the vexpress_ca15_tc2 target and
qemu-system-arm -M vexpress-a15.

commit d0c221fe7336fc7d9ada57d96f4a8911a3aac041
Author: Jean-Jacques Hiblot 
AuthorDate: Thu Sep 21 16:29:57 2017 +0200
Commit: Jaehoon Chung 
CommitDate: Fri Jan 12 18:11:04 2018 +0900

mmc: refactor SD startup to make it easier to support new modes

The SDcard startup process currently handles only 2 modes. To make it
easier to add support for more modes, let's make the process more generic
and use a list of the modes to try.
The major functional change is that when a mode fails we try the next one.
Not all modes are tried, only those supported by the card and the host.

Signed-off-by: Jean-Jacques Hiblot 
Reviewed-by: Simon Glass 

with a build from master e24bd1e79e223aa89854c0be95a53e2d538144a5

U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:31:54 +1300)

DRAM:  1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
unable to select a mode
mmc_init: -524, time 23
unable to select a mode
mmc_init: -524, time 22
** Bad device mmc 0 **
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
unable to select a mode
mmc_init: -524, time 21
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disks on mmc...
unable to select a mode
mmc_init: -524, time 21
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
> On 02/08/2018 10:49 AM, Jonathan Gray wrote:
> > On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
> >> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> >>>
> >>>
> >>>> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <j...@jsg.id.au>:
> >>>>
> >>>> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> >>>>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
> >>>>>> From: Jonathan Gray <j...@jsg.id.au>
> >>>>>>
> >>>>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> >>>>>>>> failed(6). will try /bsd
> >>>>>>>
> >>>>>>> How do you find out that it's sd0a instead of sd1a?
> >>>>>>
> >>>>>> The loaded image protocol I believe.
> >>>>>
> >>>>> Actually the OpenBSD bootloader currently only supports loading the
> >>>>> bsd kernel from the same device as the bootloader.  It will always
> >>>>> call that device sd0.  It invokes the device path protocol on the
> >>>>> loaded image handle and then matches that path to a device that
> >>>>> supports the block io protocol.
> >>>>
> >>>> Perhaps the problem is elsewhere as U-Boot master also broke
> >>>> vexpress_ca15_tc2 and mx6cuboxi targets:
> >>>
> >>> Perfect, so can you quickly bisect it now that the bisect doesn???t end 
> >>> at the pinctrl driver?
> >>
> >> On cubox a bisect points to
> >>
> >> commit 64e4db0f119151a1345e1da19d152eda550394e7
> >> Author: Heinrich Schuchardt <xypron.g...@gmx.de>
> >> Date:   Fri Jan 19 20:24:47 2018 +0100
> >>
> >> efi_loader: make efi_disk_create_partitions a global symbol
> >> 
> >> Up to now we have been using efi_disk_create_partitions() to create
> >> partitions for block devices that existed before starting an EFI
> >> application.
> >> 
> >> We need to call it for block devices created by EFI
> >> applications at run time. The EFI application will define the
> >> handle for the block device and install a device path protocol
> >> on it. We have to use this device path as stem for the partition
> >> device paths.
> >> 
> >> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> >> Signed-off-by: Alexander Graf <ag...@suse.de>
> >>
> >>  include/efi_loader.h  |  4 +++
> >>  lib/efi_loader/efi_disk.c | 84 
> >> +++
> >>  2 files changed, 64 insertions(+), 24 deletions(-)
> >>
> >> If I revert this commit a image built from master works.
> > 
> > Actually master doesn't build with just that reverted, seems I had stale
> > object files.
> 
> When bisecting running
> 'make mrproper && make foo_defconfig && make'
> in each round is recommendable.
> 
> Do you still assume a problem that requires a change in U-Boot?
> Or can we close the topic?
> 
> Best regards
> 
> Heinrich

There are multiple regressions with U-Boot master compared to 2018.01.

sopine_baseboard (pinebook), reported to me I don't have hardware
rpi_3
mx6cuboxi
vexpress_ca15_tc2

While qemu_arm64 works.

Bisecting rpi_3 again, removing obj dir between runs and skipping
commits where nothing shows up on serial again gives the same:

commit caf2233b281c03e3e359061a3dfa537d8a25c273
Author: Alexander Graf <ag...@suse.de>
AuthorDate: Tue Jan 23 18:05:21 2018 +0100
Commit: Tom Rini <tr...@konsulko.com>
CommitDate: Sun Jan 28 12:27:32 2018 -0500

bcm283x: Add pinctrl driver

The bcm283x family of SoCs have a GPIO controller that also acts as
pinctrl controller.

This patch introduces a new pinctrl driver that can actually properly mux
devices into their device tree defined pin states and is now the primary
owner of the gpio device. The previous GPIO driver gets moved into a
subdevice of the pinctrl driver, bound to the same OF node.

That way whenever a device asks for pinctrl support, it gets it
automatically from the pinctrl driver and GPIO support is still available
in the normal command line phase.

Signed-off-by: Alexander Graf <ag...@suse.de>

with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5

U-Boot 2018.03-rc1-00185-g1e19c70639

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> > 
> > 
> > > Am 08.02.2018 um 06:49 schrieb Jonathan Gray <j...@jsg.id.au>:
> > > 
> > > On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> > >>> Date: Mon, 5 Feb 2018 21:06:59 +1100
> > >>> From: Jonathan Gray <j...@jsg.id.au>
> > >>> 
> > >>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > >>>>> failed(6). will try /bsd
> > >>>> 
> > >>>> How do you find out that it's sd0a instead of sd1a?
> > >>> 
> > >>> The loaded image protocol I believe.
> > >> 
> > >> Actually the OpenBSD bootloader currently only supports loading the
> > >> bsd kernel from the same device as the bootloader.  It will always
> > >> call that device sd0.  It invokes the device path protocol on the
> > >> loaded image handle and then matches that path to a device that
> > >> supports the block io protocol.
> > > 
> > > Perhaps the problem is elsewhere as U-Boot master also broke
> > > vexpress_ca15_tc2 and mx6cuboxi targets:
> > 
> > Perfect, so can you quickly bisect it now that the bisect doesn???t end at 
> > the pinctrl driver?
> 
> On cubox a bisect points to
> 
> commit 64e4db0f119151a1345e1da19d152eda550394e7
> Author: Heinrich Schuchardt <xypron.g...@gmx.de>
> Date:   Fri Jan 19 20:24:47 2018 +0100
> 
> efi_loader: make efi_disk_create_partitions a global symbol
> 
> Up to now we have been using efi_disk_create_partitions() to create
> partitions for block devices that existed before starting an EFI
> application.
> 
> We need to call it for block devices created by EFI
> applications at run time. The EFI application will define the
> handle for the block device and install a device path protocol
> on it. We have to use this device path as stem for the partition
> device paths.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> Signed-off-by: Alexander Graf <ag...@suse.de>
> 
>  include/efi_loader.h  |  4 +++
>  lib/efi_loader/efi_disk.c | 84 
> +++
>  2 files changed, 64 insertions(+), 24 deletions(-)
> 
> If I revert this commit a image built from master works.

Actually master doesn't build with just that reverted, seems I had stale
object files.

rpi3 with the commit just before boots

98d48bdf415e318a11f9f9a44dff2b70aef3fb10
efi_loader: provide a function to create a partition node

U-Boot 2018.01-00408-gb7b3517a7f (Feb 08 2018 - 22:35:55 +1300)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e30: 0
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
Type: Removable Hard Disk
Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
unhandled parent class: usb_mass_storage.lun0 (13)
82748 bytes read in 89 ms (907.2 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
unhandled parent class: sd...@7e30.blk (13)
unhandled parent class: sd...@7e30.blk (13)
unhandled parent class: sd...@7e30.blk (13)
Scanning disk usb_mass_storage.lun0...
unhandled parent class: usb_mass_storage.lun0 (13)
unhandled parent class: usb_mass_storage.lun0 (13)
unhandled parent class: usb_mass_storage.lun0 (13)
Found 6 disks
>> OpenBSD/arm64 BOOTAA64 0.11
boot>
booting sd0a:/bsd: 
3917796+579072+585220+806860-[280094+96+459168+244083]=0x8442a8
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> 
> 
> > Am 08.02.2018 um 06:49 schrieb Jonathan Gray <j...@jsg.id.au>:
> > 
> > On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> >>> Date: Mon, 5 Feb 2018 21:06:59 +1100
> >>> From: Jonathan Gray <j...@jsg.id.au>
> >>> 
> >>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> >>>>> failed(6). will try /bsd
> >>>> 
> >>>> How do you find out that it's sd0a instead of sd1a?
> >>> 
> >>> The loaded image protocol I believe.
> >> 
> >> Actually the OpenBSD bootloader currently only supports loading the
> >> bsd kernel from the same device as the bootloader.  It will always
> >> call that device sd0.  It invokes the device path protocol on the
> >> loaded image handle and then matches that path to a device that
> >> supports the block io protocol.
> > 
> > Perhaps the problem is elsewhere as U-Boot master also broke
> > vexpress_ca15_tc2 and mx6cuboxi targets:
> 
> Perfect, so can you quickly bisect it now that the bisect doesn???t end at 
> the pinctrl driver?

On cubox a bisect points to

commit 64e4db0f119151a1345e1da19d152eda550394e7
Author: Heinrich Schuchardt <xypron.g...@gmx.de>
Date:   Fri Jan 19 20:24:47 2018 +0100

efi_loader: make efi_disk_create_partitions a global symbol

Up to now we have been using efi_disk_create_partitions() to create
partitions for block devices that existed before starting an EFI
application.

We need to call it for block devices created by EFI
applications at run time. The EFI application will define the
handle for the block device and install a device path protocol
on it. We have to use this device path as stem for the partition
device paths.

Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
Signed-off-by: Alexander Graf <ag...@suse.de>

 include/efi_loader.h  |  4 +++
 lib/efi_loader/efi_disk.c | 84 
+++
 2 files changed, 64 insertions(+), 24 deletions(-)

If I revert this commit a image built from master works.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> > Date: Mon, 5 Feb 2018 21:06:59 +1100
> > From: Jonathan Gray <j...@jsg.id.au>
> > 
> > > > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > > >  failed(6). will try /bsd
> > > 
> > > How do you find out that it's sd0a instead of sd1a?
> > 
> > The loaded image protocol I believe.
> 
> Actually the OpenBSD bootloader currently only supports loading the
> bsd kernel from the same device as the bootloader.  It will always
> call that device sd0.  It invokes the device path protocol on the
> loaded image handle and then matches that path to a device that
> supports the block io protocol.

Perhaps the problem is elsewhere as U-Boot master also broke
vexpress_ca15_tc2 and mx6cuboxi targets:

$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb 
/usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel 
/usr/local/share/u-boot/vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and 
probing guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.


U-Boot 2018.01 (Feb 06 2018 - 23:26:43 -0700)

DRAM:  1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
reading fdt.dtb
13384 bytes read in 2153 ms (5.9 KiB/s)
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
76528 bytes read in 51 ms (1.4 MiB/s)
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 3 disks
WARNING: Invalid device tree, expect boot to fail
>> OpenBSD/armv7 BOOTARM 1.0
boot>
cannot open sd0a:/etc/random.seed: No such file or directory
booting sd0a:/bsd: 2648671+8030940+445060 [168774+90+179792+153619]=0xb1812c

$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb 
/usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel 
vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and 
probing guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 18:24:11 +1300)

DRAM:  1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
unable to select a mode
mmc_init: -524, time 22
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
unable to select a mode
mmc_init: -524, time 21
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disks on mmc...
unable to select a mode
mmc_init: -524, time 21
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 2147483646

U-Boot SPL 2018.01 (Feb 06 2018 - 23:13:29)
Trying to boot from MMC1


U-Boot 2018.01 (Feb 06 2018 - 23:13:29 -0700)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 54C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /imx6q-cubox-i.dtb
37503 bytes read in 19 ms (1.9 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Scanning disks on sata...
Found 8 disks
reading efi/boot/bootarm.efi
76528 bytes read in 32 ms (2.3 MiB/s)
## Starting EFI application at 1200 ...
>> OpenBSD/armv7 BOOTARM 1.0
boot>
booting sd0a:/bsd: 4531856+203028+560156\[277405+90+281904+244582]=0x5d6b88


U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:54:19 +1300)
Trying to boot from MMC1


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Mon, Feb 05, 2018 at 09:37:15AM +0100, Alexander Graf wrote:
> 
> 
> On 03.02.18 12:38, Jonathan Gray wrote:
> > On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 03.02.18 02:47, Jonathan Gray wrote:
> >>> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> >>>> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> >>>>
> >>>>> The bcm283x family of SoCs have a GPIO controller that also acts as
> >>>>> pinctrl controller.
> >>>>>
> >>>>> This patch introduces a new pinctrl driver that can actually properly 
> >>>>> mux
> >>>>> devices into their device tree defined pin states and is now the primary
> >>>>> owner of the gpio device. The previous GPIO driver gets moved into a
> >>>>> subdevice of the pinctrl driver, bound to the same OF node.
> >>>>>
> >>>>> That way whenever a device asks for pinctrl support, it gets it
> >>>>> automatically from the pinctrl driver and GPIO support is still 
> >>>>> available
> >>>>> in the normal command line phase.
> >>>>>
> >>>>> Signed-off-by: Alexander Graf <ag...@suse.de>
> >>>>
> >>>> Applied to u-boot/master, thanks!
> >>>
> >>> It seems one of the recent commits here has broken booting on rpi_3 with
> >>> the vendor supplied device tree via efi_loader.
> >>
> >> Do you have a pointer to the dtb? I'm actually using the vendor supplied
> >> device tree to boot, but I don't specify it, I just leave it to the RPi
> >> fw to pass it in.
> >>
> >> Can you please go into detail on your setup?
> >>
> >>
> >> Alex
> > 
> > Sure.  Using the most recent release of the firmware
> > https://github.com/raspberrypi/firmware/releases/tag/1.20171029
> > 
> > https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb
> > 
> > dtb is placed in the root of the fat partition and loaded by the
> > firmware, it is not placed in a 'broadcom' or 'dtb' directory.
> > 
> > MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb
> > MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508
> > MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de
> > MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a
> > 
> > $ cat config.txt
> > arm_control=0x200
> > enable_uart=1
> > device_tree_address=0x100
> > kernel=u-boot.bin
> > 
> > These files are included in the installation disk image for OpenBSD/arm64
> > (along with u-boot.bin):
> > 
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> > 
> > In the setup I use U-Boot is loaded off sd card with boot target set to
> > prefer usb (fuse to enable usb boot isn't blown).  distro bootcmd finds
> > bootaa64.efi and loads that.
> > 
> > With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:
> 
> Are you using the defconfig or do you set CONFIG_OF_BOARD to fetch the
> U-Boot DT from firmware?

defconfig with no changes

> 
> > 
> > U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)
> > 
> > DRAM:  948 MiB
> > RPI 3 Model B (0xa02082)
> > MMC:   mmc@7e202000: 0, sdhci@7e30: 1
> > Loading Environment from FAT... OK
> > In:serial
> > Out:   vidconsole
> > Err:   vidconsole
> > Net:   No ethernet found.
> > starting USB...
> > USB0:   Core Release: 2.80a
> > scanning bus 0 for devices... 4 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > U-Boot> printenv
> > arch=arm
> > baudrate=115200
> > board=rpi
> > board_name=3 Model B
> > board_rev=0x8
> > board_rev_scheme=1
> > board_revision=0xA02082
> > boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} 
> > ${prefix}${script}; source ${scriptaddr}
> > boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} 
> > ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then 
> > bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} 
> > ${fdtcontroladdr};fi
> > boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any 
> > ${scriptaddr} ${prefix}extlinux/extlinux.conf
> > boot_net_us

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
> 
> 
> On 03.02.18 02:47, Jonathan Gray wrote:
> > On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> >> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> >>
> >>> The bcm283x family of SoCs have a GPIO controller that also acts as
> >>> pinctrl controller.
> >>>
> >>> This patch introduces a new pinctrl driver that can actually properly mux
> >>> devices into their device tree defined pin states and is now the primary
> >>> owner of the gpio device. The previous GPIO driver gets moved into a
> >>> subdevice of the pinctrl driver, bound to the same OF node.
> >>>
> >>> That way whenever a device asks for pinctrl support, it gets it
> >>> automatically from the pinctrl driver and GPIO support is still available
> >>> in the normal command line phase.
> >>>
> >>> Signed-off-by: Alexander Graf <ag...@suse.de>
> >>
> >> Applied to u-boot/master, thanks!
> > 
> > It seems one of the recent commits here has broken booting on rpi_3 with
> > the vendor supplied device tree via efi_loader.
> 
> Do you have a pointer to the dtb? I'm actually using the vendor supplied
> device tree to boot, but I don't specify it, I just leave it to the RPi
> fw to pass it in.
> 
> Can you please go into detail on your setup?
> 
> 
> Alex

Sure.  Using the most recent release of the firmware
https://github.com/raspberrypi/firmware/releases/tag/1.20171029

https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb

dtb is placed in the root of the fat partition and loaded by the
firmware, it is not placed in a 'broadcom' or 'dtb' directory.

MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb
MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508
MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de
MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a

$ cat config.txt
arm_control=0x200
enable_uart=1
device_tree_address=0x100
kernel=u-boot.bin

These files are included in the installation disk image for OpenBSD/arm64
(along with u-boot.bin):

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

In the setup I use U-Boot is loaded off sd card with boot target set to
prefer usb (fuse to enable usb boot isn't blown).  distro bootcmd finds
bootaa64.efi and loads that.

With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:

U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT... OK
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot> printenv
arch=arm
baudrate=115200
board=rpi
board_name=3 Model B
board_rev=0x8
board_rev_scheme=1
board_revision=0xA02082
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} 
${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} 
efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} 
${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} 
${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=usb0 mmc0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; 
then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci 
${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci 
PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp 
${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr 
${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi 
${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv 
bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv 
efi_old_vci;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=2
bootfstype=fat
cpu=armv8
devnum=0
devplist=1
devtype=usb
dhcpuboot=usb start; dhcp u-boot.uimg; bootm
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={ro,boot}(blob)
efi_dtb_prefix

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> 
> > The bcm283x family of SoCs have a GPIO controller that also acts as
> > pinctrl controller.
> > 
> > This patch introduces a new pinctrl driver that can actually properly mux
> > devices into their device tree defined pin states and is now the primary
> > owner of the gpio device. The previous GPIO driver gets moved into a
> > subdevice of the pinctrl driver, bound to the same OF node.
> > 
> > That way whenever a device asks for pinctrl support, it gets it
> > automatically from the pinctrl driver and GPIO support is still available
> > in the normal command line phase.
> > 
> > Signed-off-by: Alexander Graf 
> 
> Applied to u-boot/master, thanks!

It seems one of the recent commits here has broken booting on rpi_3 with
the vendor supplied device tree via efi_loader.

last working commit seems to be:

8996975ff8422e07f43eb8b3b0c7ed8c2b35442f
powerpc: Drop CONFIG_WALNUT and other related dead code

After that were

caf2233b281c03e3e359061a3dfa537d8a25c273
bcm283x: Add pinctrl driver

c8a73a26d6dd9b7d489e66529fe1412425d8f2d1
mmc: Add bcm2835 sdhost controller

These can't easily be reverted due to other changes.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix partition offsets

[Jonathan Gray]

On Fri, Dec 08, 2017 at 06:55:02AM +0100, Alexander Graf wrote:
> 
> 
> On 07.12.17 12:45, Jonathan Gray wrote:
> > On Thu, Dec 07, 2017 at 11:57:43AM +0100, Heinrich Schuchardt wrote:
> >> On 12/07/2017 08:00 AM, Jonathan Gray wrote:
> >>> On Fri, Dec 01, 2017 at 04:10:33PM +0100, Alexander Graf wrote:
> >>>> Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) 
> >>>> tried
> >>>> to introduce the el torito scheme to all partition table types: Spawn
> >>>> individual disk objects for each partition on a disk.
> >>>>
> >>>> Unfortunately, that code ended up creating partitions with offset=0 
> >>>> which meant
> >>>> that anyone accessing these objects gets data from the raw block device 
> >>>> instead
> >>>> of the partition.
> >>>>
> >>>> Furthermore, all the el torito logic to spawn devices for partitions was
> >>>> duplicated. So let's merge the two code paths and give partition disk 
> >>>> objects
> >>>> good offsets to work from, so that payloads can actually make use of 
> >>>> them.
> >>>>
> >>>> Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
> >>>> Reported-by: Yousaf Kaukab <yousaf.kau...@suse.com>
> >>>> Signed-off-by: Alexander Graf <ag...@suse.de>
> >>>
> >>> This once again broke being able to find a DEVICE_PATH_TYPE_MEDIA_DEVICE
> >>> node with the loaded image protocol on rpi_3 with mmc/usb.
> >>
> >> Could you, please, specify which software you are trying to call:
> >> Linux EFI stub, Grub, or anything else?
> > 
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/BOOTAA64.EFI
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/arm64/stand/efiboot/
> > Disk image with fat/ffs filesystems
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> > 
> > though it would likely show up on other archs as well
> > 
> > armv7 equivalents of the above
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/armv7/BOOTARM.EFI
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
> > 
> >>
> >> Which patches did you consider?
> >> Did you apply these patch series that are not yet in efi-next?
> >> efi_loader: correct media device paths
> >> efi_loader: avoid use after free
> > 
> > just master
> > c8e1ca3ebfd21915f6f2e399c9ca1cd3d7a4b076 tools: omapimage: fix corner-case 
> > in byteswap path
> > 
> > with a small patch to force calling gnu sed for some non-portable
> > sed use in check-config.sh
> > 
> > 'efi_loader: avoid use after free' doesn't help
> > 'efi_loader: correct media device paths' doesn't either
> 
> As a quick heads-up: The device path matching is broken. The patch below
> should fix it, but I want to create a travis-ci case around that first
> and also wrap it up more nicely.
> 
> Alex

With the latest master at the time of writing
(2e87980580d0bf4781ad0d63efd456aa1a73d03f) the rpi_3 target again
seems to be broken while it worked with the v2018.01 release.

The qemu_arm64 target however works with the latest master.

U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 01 2018 - 17:04:29 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT... OK
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
Type: Removable Hard Disk
Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
78335 bytes read in 79 ms (967.8 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk m...@7e202000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 24
Scanning disk sd...@7e30.blk...
>> OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd
boot>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd
Turning timeout off.

U-Boot 20

Re: [U-Boot] [PATCH v2 1/4] ARM: qemu-arm: Add support for AArch64

[Jonathan Gray]

On Sat, Jan 13, 2018 at 02:45:32PM +0200, Tuomas Tynkkynen wrote:
> Hi Jonathan,
> 
> On 01/13/2018 09:08 AM, Jonathan Gray wrote:
> > On Thu, Jan 11, 2018 at 04:11:23PM +0200, Tuomas Tynkkynen wrote:
> > > This adds support for '-machine virt' on AArch64. This is rather simple:
> > > we just add TARGET_QEMU_ARM_xxBIT to select a few different Kconfig
> > > symbols, provide the ARMv8 memory map from the board file and add a new
> > > defconfig based on the 32-bit defconfig.
> > 
> > While nvme is in the defconfig it seems only ahci works with
> > distroboot automatically.
> > 
> > Booting off nvme requires manually running
> > 
> > => nvme scan
> > => setenv devtype nvme
> > => run scan_dev_for_boot_part
> > 
> > Having it work automatically requires something like the below
> > 
> 
> Yeah. You should probably send that as a formal patch (or two I guess;
> one for config_distro_bootcmd.h; one for qemu-arm.h).
> 
> FWIW, I have a mostly-working virtio stack for U-Boot which probably
> would be the best disk interface for booting Linux. Still needs a
> lot of cleanup, hopefully one day it will be ready...

That would be great.  I'm interested in running OpenBSD not Linux and
ahci cant't map the interrupt with qemu (does on pci ecam + ahci on an
overdrive 1000), and nvme turns out to hang when mounting the root
filesystem.

Would be nice to be able to replace using edk2 ovmf for booting off
virtio storage.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/4] ARM: qemu-arm: Add support for AArch64

[Jonathan Gray]

On Thu, Jan 11, 2018 at 04:11:23PM +0200, Tuomas Tynkkynen wrote:
> This adds support for '-machine virt' on AArch64. This is rather simple:
> we just add TARGET_QEMU_ARM_xxBIT to select a few different Kconfig
> symbols, provide the ARMv8 memory map from the board file and add a new
> defconfig based on the 32-bit defconfig.

While nvme is in the defconfig it seems only ahci works with
distroboot automatically.

Booting off nvme requires manually running

=> nvme scan
=> setenv devtype nvme
=> run scan_dev_for_boot_part

Having it work automatically requires something like the below

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 5c469a23fa..305e102cb8 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -195,6 +195,31 @@
BOOT_TARGET_DEVICES_references_SCSI_without_CONFIG_SCSI
 #endif
 
+#ifdef CONFIG_NVME
+#define BOOTENV_RUN_NVME_INIT "run nvme_init; "
+#define BOOTENV_SET_NVME_NEED_INIT "setenv nvme_need_init; "
+#define BOOTENV_SHARED_NVME \
+   "nvme_init=" \
+   "if ${nvme_need_init}; then " \
+   "setenv nvme_need_init false; " \
+   "nvme scan; " \
+   "fi\0" \
+   \
+   "nvme_boot=" \
+   BOOTENV_RUN_NVME_INIT \
+   BOOTENV_SHARED_BLKDEV_BODY(nvme)
+#define BOOTENV_DEV_NVME   BOOTENV_DEV_BLKDEV
+#define BOOTENV_DEV_NAME_NVME  BOOTENV_DEV_NAME_BLKDEV
+#else
+#define BOOTENV_RUN_NVME_INIT
+#define BOOTENV_SET_NVME_NEED_INIT
+#define BOOTENV_SHARED_NVME
+#define BOOTENV_DEV_NVME \
+   BOOT_TARGET_DEVICES_references_NVME_without_CONFIG_NVME
+#define BOOTENV_DEV_NAME_NVME \
+   BOOT_TARGET_DEVICES_references_NVME_without_CONFIG_NVME
+#endif
+
 #ifdef CONFIG_IDE
 #define BOOTENV_SHARED_IDE BOOTENV_SHARED_BLKDEV(ide)
 #define BOOTENV_DEV_IDEBOOTENV_DEV_BLKDEV
@@ -324,6 +349,7 @@
 #define BOOTENV \
BOOTENV_SHARED_HOST \
BOOTENV_SHARED_MMC \
+   BOOTENV_SHARED_NVME \
BOOTENV_SHARED_PCI \
BOOTENV_SHARED_USB \
BOOTENV_SHARED_SATA \
@@ -390,6 +416,7 @@
BOOT_TARGET_DEVICES(BOOTENV_DEV)  \
\
"distro_bootcmd=" BOOTENV_SET_SCSI_NEED_INIT  \
+   BOOTENV_SET_NVME_NEED_INIT\
"for target in ${boot_targets}; do "  \
"run bootcmd_${target}; " \
"done\0"
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index c8852cef34..8c65babb77 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -38,7 +38,8 @@
 #include 
 
 #define BOOT_TARGET_DEVICES(func) \
-   func(SCSI, scsi, 0)
+   func(SCSI, scsi, 0) \
+   func(NVME, nvme, 0)
 
 #include 
 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PULL] efi patch queue 2017-12-17

[Jonathan Gray]

On Sun, Dec 17, 2017 at 09:33:44PM +0100, Alexander Graf wrote:
> Hi Tom,
> 
> This is my current patch queue for efi.  Please pull.
> 
> Alex
> 
> 
> The following changes since commit 15616a0aa58173bce1efe47569bf2e10d023ae9c:
> 
>   Merge git://git.denx.de/u-boot-dm (2017-12-14 15:46:07 -0500)
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/u-boot.git tags/signed-efi-v2018.01
> 
> for you to fetch changes up to bde6bfe4c3234480a0eef3b5bda8cf5fc83d3c79:
> 
>   efi_loader: comments for dp_part_fill() (2017-12-16 23:07:56 +0100)
> 
> 
> Patch queue for efi - 2017-12-17
> 
> A few fixes for 2018.01:
> 
>   - Compile fix with helloworld example
>   - DP match fix (fixes FreeBSD loader and grub on block storage)

This was for the OpenBSD bootloader, FreeBSD has a different one.
I'd test again but am away from hardware for a few days.

>   - More DP fixes for SD, block
>   - Fix use-after-free
> 
> 
> Alexander Graf (3):
>   efi_loader: helloworld.c: Explicitly use .rodata for loaded_image_guid
>   efi_loader: helloworld.c: Reduce file size
>   efi_loader: Ensure efi_dp_find_obj() finds exact matches
> 
> Heinrich Schuchardt (7):
>   efi_loader: return status from efi_setup_loaded_image()
>   efi_loader: new function efi_delete_handle()
>   efi_loader: error handling in efi_load_image()
>   efi_loader: correctly determine if an MMC device is an SD-card
>   efi_loader: correctly setup device paths for block devices
>   efi_loader: correct DeviceNodeToText for media types
>   efi_loader: comments for dp_part_fill()
> 
>  arch/arm/lib/elf_arm_efi.lds |  11 +-
>  include/efi_loader.h |  10 +-
>  lib/efi_loader/efi_boottime.c| 228 
> +--
>  lib/efi_loader/efi_device_path.c |  56 ++--
>  lib/efi_loader/efi_device_path_to_text.c |  43 --
>  lib/efi_loader/helloworld.c  |   3 +-
>  6 files changed, 214 insertions(+), 137 deletions(-)
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix partition offsets

[Jonathan Gray]

On Fri, Dec 08, 2017 at 08:09:46AM +0100, Heinrich Schuchardt wrote:
> On 12/07/2017 08:00 AM, Jonathan Gray wrote:
> > On Fri, Dec 01, 2017 at 04:10:33PM +0100, Alexander Graf wrote:
> > > Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) 
> > > tried
> > > to introduce the el torito scheme to all partition table types: Spawn
> > > individual disk objects for each partition on a disk.
> > > 
> > > Unfortunately, that code ended up creating partitions with offset=0 which 
> > > meant
> > > that anyone accessing these objects gets data from the raw block device 
> > > instead
> > > of the partition.
> 
> Hello Jonathan,
> 
> according to the UEFI standard the whole disk may be represented by as
> partition number 0 (with offset 0).

You are quoting Alexander there not me.

> 
> UEFI spec 2.7:
> 10.3.6.1 Hard Drive
> A partition number of zero can be used to represent the raw hard drive or a
> raw extended partition.
> 
> Do you have access to the source of the BSD loader that you are calling?
> Please, check that it complies to this aspect of the UEFI API.

Already mentioned in this thread, but again:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/arm64/stand/efiboot/

Which works fine with the EDK2 based firmware on the overdrive 1000.
And has found various regressions in changes made to the efi loader in
U-Boot over the last few months.

> 
> Best regards
> 
> Heinrich
> 
> 
> > > 
> > > Furthermore, all the el torito logic to spawn devices for partitions was
> > > duplicated. So let's merge the two code paths and give partition disk 
> > > objects
> > > good offsets to work from, so that payloads can actually make use of them.
> > > 
> > > Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
> > > Reported-by: Yousaf Kaukab <yousaf.kau...@suse.com>
> > > Signed-off-by: Alexander Graf <ag...@suse.de>
> > 
> > This once again broke being able to find a DEVICE_PATH_TYPE_MEDIA_DEVICE
> > node with the loaded image protocol on rpi_3 with mmc/usb.
> > 
> > broken
> > ## Starting EFI application at 0100 ...
> > Scanning disk sd...@7e30.blk...
> > efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
> > if_typename=mmc_blk, dev_index=0 offset=0, part=0
> > efi_disk_create_partitions efi_disk_add_dev name=sd...@7e30.blk:1, 
> > if_typename=mmc_blk, dev_index=0 offset=8192, part=1
> > efi_disk_create_partitions efi_disk_add_dev name=sd...@7e30.blk:4, 
> > if_typename=mmc_blk, dev_index=0 offset=16384, part=4
> > Scanning disk usb_mass_storage.lun0...
> > efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, 
> > if_typename=usb_storage_blk, dev_index=0 offset=0, part=0
> > efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:1, 
> > if_typename=usb_storage_blk, dev_index=0 offset=8192, part=1
> > efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:4, 
> > if_typename=usb_storage_blk, dev_index=0 offset=40960, part=4
> > Found 6 disks
> > efi_dp_match a: len 20 type 1 b: len 20 type: 1
> > efi_dp_match a: len 20 type 1 b: len 20 type: 1
> > efi_dp_match a: len 20 type 1 b: len 20 type: 1
> > efi_dp_match a: len 20 type 1 b: len 20 type: 1
> > efi_dp_match a: len 11 type 3 b: len 11 type: 3
> > efi_dp_match a: len 11 type 3 b: len 11 type: 3
> > efi_dp_match a: len 11 type 3 b: len 11 type: 3
> > efi_diskprobe
> > efi_device_path_depth looking for type 4 i=0 type 1
> > efi_device_path_depth looking for type 4 i=1 type 3
> > efi_device_path_depth looking for type 4 i=2 type 3
> > efi_device_path_depth looking for type 4 i=3 type 3
> > efi_device_path_depth no match for type 4
> > depth=-1
> > 
> > working (this commit reverted)
> > ## Starting EFI application at 0100 ...
> > Scanning disk sd...@7e30.blk...
> > efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
> > if_typename=mmc_blk, dev_index=0 offset=0, part=1
> > efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
> > if_typename=mmc_blk, dev_index=0 offset=0, part=4
> > efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
> > if_typename=mmc_blk, dev_index=0 offset=0, part=0
> > Scanning disk usb_mass_storage.lun0...
> > efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, 
> > if_typename=usb_storage_blk, dev_index=0 offset=0, part=1
> > efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, 
> > if_typename=usb_storage_

Re: [U-Boot] [PATCH] efi_loader: Fix partition offsets

[Jonathan Gray]

On Fri, Dec 08, 2017 at 06:55:02AM +0100, Alexander Graf wrote:
> 
> 
> On 07.12.17 12:45, Jonathan Gray wrote:
> > On Thu, Dec 07, 2017 at 11:57:43AM +0100, Heinrich Schuchardt wrote:
> >> On 12/07/2017 08:00 AM, Jonathan Gray wrote:
> >>> On Fri, Dec 01, 2017 at 04:10:33PM +0100, Alexander Graf wrote:
> >>>> Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) 
> >>>> tried
> >>>> to introduce the el torito scheme to all partition table types: Spawn
> >>>> individual disk objects for each partition on a disk.
> >>>>
> >>>> Unfortunately, that code ended up creating partitions with offset=0 
> >>>> which meant
> >>>> that anyone accessing these objects gets data from the raw block device 
> >>>> instead
> >>>> of the partition.
> >>>>
> >>>> Furthermore, all the el torito logic to spawn devices for partitions was
> >>>> duplicated. So let's merge the two code paths and give partition disk 
> >>>> objects
> >>>> good offsets to work from, so that payloads can actually make use of 
> >>>> them.
> >>>>
> >>>> Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
> >>>> Reported-by: Yousaf Kaukab <yousaf.kau...@suse.com>
> >>>> Signed-off-by: Alexander Graf <ag...@suse.de>
> >>>
> >>> This once again broke being able to find a DEVICE_PATH_TYPE_MEDIA_DEVICE
> >>> node with the loaded image protocol on rpi_3 with mmc/usb.
> >>
> >> Could you, please, specify which software you are trying to call:
> >> Linux EFI stub, Grub, or anything else?
> > 
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/BOOTAA64.EFI
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/arm64/stand/efiboot/
> > Disk image with fat/ffs filesystems
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> > 
> > though it would likely show up on other archs as well
> > 
> > armv7 equivalents of the above
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/armv7/BOOTARM.EFI
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
> > 
> >>
> >> Which patches did you consider?
> >> Did you apply these patch series that are not yet in efi-next?
> >> efi_loader: correct media device paths
> >> efi_loader: avoid use after free
> > 
> > just master
> > c8e1ca3ebfd21915f6f2e399c9ca1cd3d7a4b076 tools: omapimage: fix corner-case 
> > in byteswap path
> > 
> > with a small patch to force calling gnu sed for some non-portable
> > sed use in check-config.sh
> > 
> > 'efi_loader: avoid use after free' doesn't help
> > 'efi_loader: correct media device paths' doesn't either
> 
> As a quick heads-up: The device path matching is broken. The patch below
> should fix it, but I want to create a travis-ci case around that first
> and also wrap it up more nicely.
> 
> Alex

Yes, this does fix it.  Thanks.

Your mail client wrapped lines so I had to adjust it to apply.  Including
it again with that fixed:

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index b4e2f933cb..24a4f40c00 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -126,6 +126,7 @@ static struct efi_object *find_obj(struct efi_device_path 
*dp, bool short_path,
   struct efi_device_path **rem)
 {
struct efi_object *efiobj;
+   unsigned int dp_size = efi_dp_size(dp);
 
list_for_each_entry(efiobj, _obj_list, link) {
struct efi_handler *handler;
@@ -141,10 +142,18 @@ static struct efi_object *find_obj(struct efi_device_path 
*dp, bool short_path,
do {
if (efi_dp_match(dp, obj_dp) == 0) {
if (rem) {
+   /*
+* Allow partial matches, but inform
+* the caller.
+*/
*rem = ((void *)dp) +
efi_dp_size(obj_dp);
+   return efiobj;
+   } else {
+   /* Only return on exact matches */
+   if (efi_dp_size(obj_dp) == dp_size)
+

Re: [U-Boot] [PATCH] efi_loader: Fix partition offsets

[Jonathan Gray]

On Thu, Dec 07, 2017 at 11:57:43AM +0100, Heinrich Schuchardt wrote:
> On 12/07/2017 08:00 AM, Jonathan Gray wrote:
> > On Fri, Dec 01, 2017 at 04:10:33PM +0100, Alexander Graf wrote:
> >> Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) 
> >> tried
> >> to introduce the el torito scheme to all partition table types: Spawn
> >> individual disk objects for each partition on a disk.
> >>
> >> Unfortunately, that code ended up creating partitions with offset=0 which 
> >> meant
> >> that anyone accessing these objects gets data from the raw block device 
> >> instead
> >> of the partition.
> >>
> >> Furthermore, all the el torito logic to spawn devices for partitions was
> >> duplicated. So let's merge the two code paths and give partition disk 
> >> objects
> >> good offsets to work from, so that payloads can actually make use of them.
> >>
> >> Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
> >> Reported-by: Yousaf Kaukab <yousaf.kau...@suse.com>
> >> Signed-off-by: Alexander Graf <ag...@suse.de>
> > 
> > This once again broke being able to find a DEVICE_PATH_TYPE_MEDIA_DEVICE
> > node with the loaded image protocol on rpi_3 with mmc/usb.
> 
> Could you, please, specify which software you are trying to call:
> Linux EFI stub, Grub, or anything else?

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/BOOTAA64.EFI
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/arm64/stand/efiboot/
Disk image with fat/ffs filesystems
https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

though it would likely show up on other archs as well

armv7 equivalents of the above
https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/armv7/BOOTARM.EFI
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/
https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs

> 
> Which patches did you consider?
> Did you apply these patch series that are not yet in efi-next?
> efi_loader: correct media device paths
> efi_loader: avoid use after free

just master
c8e1ca3ebfd21915f6f2e399c9ca1cd3d7a4b076 tools: omapimage: fix corner-case in 
byteswap path

with a small patch to force calling gnu sed for some non-portable
sed use in check-config.sh

'efi_loader: avoid use after free' doesn't help
'efi_loader: correct media device paths' doesn't either

> 
> Regards
> 
> Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix partition offsets

[Jonathan Gray]

On Fri, Dec 01, 2017 at 04:10:33PM +0100, Alexander Graf wrote:
> Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) tried
> to introduce the el torito scheme to all partition table types: Spawn
> individual disk objects for each partition on a disk.
> 
> Unfortunately, that code ended up creating partitions with offset=0 which 
> meant
> that anyone accessing these objects gets data from the raw block device 
> instead
> of the partition.
> 
> Furthermore, all the el torito logic to spawn devices for partitions was
> duplicated. So let's merge the two code paths and give partition disk objects
> good offsets to work from, so that payloads can actually make use of them.
> 
> Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
> Reported-by: Yousaf Kaukab 
> Signed-off-by: Alexander Graf 

This once again broke being able to find a DEVICE_PATH_TYPE_MEDIA_DEVICE
node with the loaded image protocol on rpi_3 with mmc/usb.

broken
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
if_typename=mmc_blk, dev_index=0 offset=0, part=0
efi_disk_create_partitions efi_disk_add_dev name=sd...@7e30.blk:1, 
if_typename=mmc_blk, dev_index=0 offset=8192, part=1
efi_disk_create_partitions efi_disk_add_dev name=sd...@7e30.blk:4, 
if_typename=mmc_blk, dev_index=0 offset=16384, part=4
Scanning disk usb_mass_storage.lun0...
efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, 
if_typename=usb_storage_blk, dev_index=0 offset=0, part=0
efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:1, 
if_typename=usb_storage_blk, dev_index=0 offset=8192, part=1
efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:4, 
if_typename=usb_storage_blk, dev_index=0 offset=40960, part=4
Found 6 disks
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 11 type 3 b: len 11 type: 3
efi_dp_match a: len 11 type 3 b: len 11 type: 3
efi_dp_match a: len 11 type 3 b: len 11 type: 3
efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 1
efi_device_path_depth looking for type 4 i=1 type 3
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 3
efi_device_path_depth no match for type 4
depth=-1

working (this commit reverted)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
if_typename=mmc_blk, dev_index=0 offset=0, part=1
efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
if_typename=mmc_blk, dev_index=0 offset=0, part=4
efi_disk_register BLK efi_disk_add_dev name=sd...@7e30.blk, 
if_typename=mmc_blk, dev_index=0 offset=0, part=0
Scanning disk usb_mass_storage.lun0...
efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, 
if_typename=usb_storage_blk, dev_index=0 offset=0, part=1
efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, 
if_typename=usb_storage_blk, dev_index=0 offset=0, part=4
efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, 
if_typename=usb_storage_blk, dev_index=0 offset=0, part=0
Found 2 disks
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 20 type 1 b: len 20 type: 1
efi_dp_match a: len 11 type 3 b: len 11 type: 3
efi_dp_match a: len 11 type 3 b: len 11 type: 3
efi_dp_match a: len 11 type 3 b: len 11 type: 3
efi_dp_match a: len 42 type 4 b: len 42 type: 4
efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 1
efi_device_path_depth looking for type 4 i=1 type 3
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 3
efi_device_path_depth looking for type 4 i=4 type 4
depth=4

> ---
>  lib/efi_loader/efi_disk.c | 60 
> ++-
>  1 file changed, 13 insertions(+), 47 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index 68ba2cf7b2..4e457a841b 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -264,21 +264,17 @@ out_of_memory:
>   printf("ERROR: Out of memory\n");
>  }
>  
> -static int efi_disk_create_eltorito(struct blk_desc *desc,
> - const char *if_typename,
> - int diskid,
> - const char *pdevname)
> +static int efi_disk_create_partitions(struct blk_desc *desc,
> +   const char *if_typename,
> +   int diskid,
> +   const char *pdevname)
>  {
>   int disks = 0;
> -#if 

Re: [U-Boot] [PATCH] efi_loader: initialise partition_signature memory

[Jonathan Gray]

On Thu, Nov 30, 2017 at 09:24:36AM -0500, Rob Clark wrote:
> On Tue, Nov 21, 2017 at 7:24 AM, Jonathan Gray <j...@jsg.id.au> wrote:
> > Zero partition_signature in the efi_device_path_hard_drive_path
> > structure when signature_type is zero.
> >
> > This is required so that efi_dp_match() will work as expected
> > when doing memcmp() comparisons.
> >
> > Corrects a problem where the loaded image protocol would not return a
> > device path with MEDIA_DEVICE causing the OpenBSD bootloader to fail
> > on rpi_3 and other targets.
> >
> > Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> 
> Reviewed-by: Rob Clark <robdcl...@gmail.com>

Expanded v2 version of this is here:
https://patchwork.ozlabs.org/patch/840248/

> 
> > ---
> >  lib/efi_loader/efi_device_path.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_device_path.c 
> > b/lib/efi_loader/efi_device_path.c
> > index f6e368e029..8045532a29 100644
> > --- a/lib/efi_loader/efi_device_path.c
> > +++ b/lib/efi_loader/efi_device_path.c
> > @@ -431,6 +431,9 @@ static void *dp_part_fill(void *buf, struct blk_desc 
> > *desc, int part)
> > if (hddp->signature_type != 0)
> > memcpy(hddp->partition_signature, >guid_sig,
> >sizeof(hddp->partition_signature));
> > +   else
> > +   memset(hddp->partition_signature, 0,
> > +  sizeof(hddp->partition_signature));
> >
> > buf = [1];
> > }
> > --
> > 2.15.0
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] efi_loader: initialise partition_signature memory

[Jonathan Gray]

Zero partition_signature in the efi_device_path_hard_drive_path
structure when signature_type is 0 (no signature) as required by the
UEFI specification.

This is required so that efi_dp_match() will work as expected
when doing memcmp() comparisons.  Previously uninitialised memory
would cause it not match nodes when it should have when the signature
type was not GUID.

Corrects a problem where the loaded image protocol would not return a
device path with MEDIA_DEVICE causing the OpenBSD bootloader to fail
on rpi_3 and other targets.

v2: Also handle signature_type 1 (MBR) as described in the specification

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 lib/efi_loader/efi_device_path.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index f6e368e029..12a81d311c 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -427,10 +427,27 @@ static void *dp_part_fill(void *buf, struct blk_desc 
*desc, int part)
hddp->partmap_type = 2;
else
hddp->partmap_type = 1;
-   hddp->signature_type = desc->sig_type;
-   if (hddp->signature_type != 0)
+
+   switch (desc->sig_type) {
+   case SIG_TYPE_NONE:
+   default:
+   hddp->signature_type = 0;
+   memset(hddp->partition_signature, 0,
+  sizeof(hddp->partition_signature));
+   break;
+   case SIG_TYPE_MBR:
+   hddp->signature_type = 1;
+   memset(hddp->partition_signature, 0,
+  sizeof(hddp->partition_signature));
+   memcpy(hddp->partition_signature, >mbr_sig,
+  sizeof(desc->mbr_sig));
+   break;
+   case SIG_TYPE_GUID:
+   hddp->signature_type = 2;
memcpy(hddp->partition_signature, >guid_sig,
   sizeof(hddp->partition_signature));
+   break;
+   }
 
buf = [1];
}
-- 
2.15.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] efi_loader: initialise partition_signature memory

[Jonathan Gray]

Zero partition_signature in the efi_device_path_hard_drive_path
structure when signature_type is zero.

This is required so that efi_dp_match() will work as expected
when doing memcmp() comparisons.

Corrects a problem where the loaded image protocol would not return a
device path with MEDIA_DEVICE causing the OpenBSD bootloader to fail
on rpi_3 and other targets.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 lib/efi_loader/efi_device_path.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index f6e368e029..8045532a29 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -431,6 +431,9 @@ static void *dp_part_fill(void *buf, struct blk_desc *desc, 
int part)
if (hddp->signature_type != 0)
memcpy(hddp->partition_signature, >guid_sig,
   sizeof(hddp->partition_signature));
+   else
+   memset(hddp->partition_signature, 0,
+  sizeof(hddp->partition_signature));
 
buf = [1];
}
-- 
2.15.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Jonathan Gray]

On Tue, Nov 21, 2017 at 04:59:33PM +1100, Jonathan Gray wrote:
> On Sat, Nov 18, 2017 at 03:25:29PM +1100, Jonathan Gray wrote:
> >
> > While U-Boot 2017.11 release works with vexpress/qemu with the
> > efi loader it is broken on at least rpi_3 and tinker-rk3288.
> > MEDIA_DEVICE is not found again.
> 
> The loaded image paths look like the below.
> 
> vexpress and qemu_arm (virt) have a MEDIA_DEVICE, rpi_3 and
> tinkerboard do not.
> 
> Having boot_targets load bootarm.efi from mmc on rpi_3 works but having
> it load from usb does not.

The following efi_dp_match call should match but doesn't as two bytes in
the dp path nodes differ.

Forcing this to match returns the correct dp with a MEDIA_DEVICE and allows
the system to boot.

This turns out to be the partition_signature.  It is uninitialised memory.
The diff below to zero that part of the device path node fixes the
comparison.

find_obj efi_dp_match
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00)
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00)
efi_dp_match depth 0 alen 20 blen 20
efi_dp_match A
01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8
28 f3 62 8b 
efi_dp_match B
01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8
28 f3 62 8b 
efi_dp_match depth 1 alen 11 blen 11
efi_dp_match A
03 0f 0b 00 00 00 00 00 09 00 00 
efi_dp_match B
03 0f 0b 00 00 00 00 00 09 00 00 
efi_dp_match depth 2 alen 11 blen 11
efi_dp_match A
03 0f 0b 00 24 04 14 95 09 00 02 
efi_dp_match B
03 0f 0b 00 24 04 14 95 09 00 02 
efi_dp_match depth 3 alen 11 blen 11
efi_dp_match A
03 0f 0b 00 81 07 81 55 00 00 00 
efi_dp_match B
03 0f 0b 00 81 07 81 55 00 00 00 
efi_dp_match depth 4 alen 42 blen 42
efi_dp_match A
04 01 2a 00 00 00 00 00 00 20 00 00 00 00 00 00
00 80 00 00 00 00 00 00 15 55 55 55 55 55 d5 c1
55 55 51 55 55 45 51 55 01 00 
efi_dp_match B
04 01 2a 00 00 00 00 00 00 20 00 00 00 00 00 00
00 80 00 00 00 00 00 00 57 15 05 15 55 55 55 50
d5 55 55 55 55 55 50 75 01 00

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index f6e368e029..8045532a29 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -431,6 +431,9 @@ static void *dp_part_fill(void *buf, struct blk_desc *desc, 
int part)
if (hddp->signature_type != 0)
memcpy(hddp->partition_signature, >guid_sig,
   sizeof(hddp->partition_signature));
+   else
+   memset(hddp->partition_signature, 0,
+  sizeof(hddp->partition_signature));
 
buf = [1];
}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Jonathan Gray]

On Sat, Nov 18, 2017 at 03:25:29PM +1100, Jonathan Gray wrote:
>
> While U-Boot 2017.11 release works with vexpress/qemu with the
> efi loader it is broken on at least rpi_3 and tinker-rk3288.
> MEDIA_DEVICE is not found again.

The loaded image paths look like the below.

vexpress and qemu_arm (virt) have a MEDIA_DEVICE, rpi_3 and
tinkerboard do not.

Having boot_targets load bootarm.efi from mmc on rpi_3 works but having
it load from usb does not.

vexpress
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on mmc...
efi_disk_add_dev: name: mmc0 if_typename: mmc part: 1
efi_disk_add_dev: name: mmc0 if_typename: mmc part: 4
efi_disk_add_dev: name: mmc0 if_typename: mmc part: 0
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 1 disks
reading efi/boot/bootarm.efi
67436 bytes read in 45 ms (1.4 MiB/s)
## Starting EFI application at a0008000 ...
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Usb(0x6,0x0)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi

=> dm tree
Unknown command 'dm' - try 'help'

=> part list mmc 0

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 20484096-01 0c Boot
  4 614430720   -04 a6

qemu_arm
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disk ahci_scsi.id0lun0...
efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 1
efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 4
efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 0
Found 1 disks
reading efi/boot/bootarm.efi
67436 bytes read in 9 ms (7.1 MiB/s)
## Starting EFI application at 4040 ...
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi

=> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [   ]   generic_si  |-- platform@c00
 pci[ + ]   pci_generi  |-- pcie@1000
 pci_generi [   ]   pci_generi  |   |-- pci_0:0.0
 pci_generi [   ]   pci_generi  |   |-- pci_0:1.0
 ahci   [   ]   ahci_pci|   `-- ahci_pci
 scsi   [   ]   ahci_scsi   |   `-- ahci_scsi
 serial [ + ]   serial_pl0  |-- pl011@900
 firmware   [   ]   psci`-- psci
 sysreset   [   ]   psci-sysre  `-- psci-sysreset

=> part list scsi 0

Partition Map for SCSI device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 20484096-01 0c Boot
  4 614430720   -04 a6

rpi3
U-Boot> printenv boot_targets
boot_targets=usb0 mmc0 pxe dhcp

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 1
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 4
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 0
Scanning disk usb_mass_storage.lun0...
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 1
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 4
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 0
Found 2 disks
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootaa64.efi

U-Boot> printenv boot_targets
boot_targets=mmc0 usb0 pxe dhcp

mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78623 bytes read in 31 ms (2.4 MiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 1
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 4
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 0
Scanning disk usb_mass_storage.lun0...
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 1
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 4
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 0
Found 2 disks
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootaa64.efi

U-Boot> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [ + ]   generic_si  |-- s

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Jonathan Gray]

On Tue, Oct 10, 2017 at 04:48:01AM +1100, Jonathan Gray wrote:
> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
> > On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <j...@jsg.id.au> wrote:
> > > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> > >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <j...@jsg.id.au> wrote:
> > >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> > >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <j...@jsg.id.au> wrote:
> > >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> > >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <j...@jsg.id.au> 
> > >> >> >> wrote:
> > >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> > >> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think 
> > >> >> >> >> should also
> > >> >> >> >> fix a similar issue with grub2 on legacy devices.  In the 
> > >> >> >> >> legacy case
> > >> >> >> >> we were creating disk objects for the partitions, but not also 
> > >> >> >> >> the
> > >> >> >> >> parent device.
> > >> >> >> >>
> > >> >> >> >> Reported-by: Jonathan Gray <j...@jsg.id.au>
> > >> >> >> >> Signed-off-by: Rob Clark <robdcl...@gmail.com>
> > >> >> >> >
> > >> >> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
> > >> >> >> > boot again on cubox-i and bbb it doesn't help rpi3.
> > >> >> >> >
> > >> >> >> > What is the easiest way to get U-Boot to display these paths
> > >> >> >> > to be able to compare the current behaviour to 2017.09?
> > >> >> >> >
> > >> >> >>
> > >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD
> > >> >> >> bootloader has something similar?
> > >> >> >>
> > >> >> >> u-boot implements that device-path to text protocol, so it should 
> > >> >> >> be
> > >> >> >> pretty easy to implement something like this if not.
> > >> >> >>
> > >> >> >> BR,
> > >> >> >> -R
> > >> >> >
> > >> >> > With git + your patch a node with type 4 
> > >> >> > (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> > >> >> > is no longer seen.  Is it possible having U-Boot on mmc but 
> > >> >> > directing
> > >> >> > it to load off usb is somehow involved here?
> > >> >>
> > >> >> There is no requirement that efi payload and u-boot are on the same
> > >> >> device.  The distro bootcmd stuff will just look for
> > >> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
> > >> >> one.
> > >> >>
> > >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
> > >> >> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
> > >> >> or legacy boards, in the former case we can construct something more
> > >> >> realistic.  Although the bootloader shouldn't really care.
> > >> >
> > >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> > >> > in master only gives types of 1 (Hardware Device Path) and
> > >> > 3 (Messaging Device Path).
> > >> >
> > >> > It is DM in this case:
> > >>
> > >> Possibly something weird with your partition table?  In
> > >> efi_disk_register() it should create objects for the disk itself
> > >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> > >> partition (part>=1, which would have same dp as the disk but
> > >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> > >>
> > >> If part_get_info() fails for part==1 then you won't get any of the
> > >> partition devices.  I suppose this could happen if you an unknown
> > >> partition table type, or u-boot is not built w/ the correct partition
> > >> 

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Jonathan Gray]

On Thu, Oct 19, 2017 at 10:51:04AM +0200, Alexander Graf wrote:
> On 10/19/2017 10:26 AM, Maxime Ripard wrote:
> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> > trip across the size limit we've had on the U-Boot binary.
> > 
> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> > so that we get back some extra room for user customisations.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Quite the contrary - it is essential. All major distributions are going for
> distro boot + EFI at least for 64bit platforms now. Disabling it by default
> means you basically kill your user base on those.

EFI is mandatory for 32 and 64 bit OpenBSD arm.  I would not be
surprised if others made similiar choices to be able to boot off
filesystems unsupported by U-Boot and have something close to a real
firmware interface.

> 
> > ---
> >   lib/efi_loader/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index d2b6327119b4..a80a914b2fe8 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -1,7 +1,7 @@
> >   config EFI_LOADER
> > bool "Support running EFI Applications in U-Boot"
> > depends on (ARM || X86) && OF_LIBFDT
> > -   default y
> > +   default y if !ARCH_SUNXI
> 
> Nack on any change to that default line. If you must disable efi_loader (and
> really, I strongly advise not to do so for sunxi), please do so in the
> defconfigs, as nothing prohibits the architecture to work with it.
> 
> 
> Alex
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] efi_loader triggers fec_mxc messages when booting off mmc

[Jonathan Gray]

After the recent changes to add SimpleNetworkProtocol to efi_loader
when booting off mmc via an efi payload that doesn't use
SimpleNetworkProtocol U-Boot's fec_mxc driver will now display
various "error frame" messages.

U-Boot SPL 2017.11-rc1-00277-g7b342d8c5d (Oct 15 2017 - 12:55:50)
Trying to boot from MMC1


U-Boot 2017.11-rc1-00277-g7b342d8c5d (Oct 15 2017 - 12:55:50 +1100)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 32C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /imx6q-cubox-i.dtb
37669 bytes read in 20 ms (1.8 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Scanning disks on sata...
Found 6 disks
reading efi/boot/bootarm.efi
67372 bytes read in 32 ms (2 MiB/s)
## Starting EFI application at 1200 ...
>> OpenBSD/armv7 BOOTARM 1.0
error frame: 0x8f57ec40 0x3d74
error frame: 0x8f57ec40 0x7079
error frame: 0x8f57ec40 0x6964
error frame: 0x8f57ec40 0x6f6f
error frame: 0x8f57ec40 0x726f
error frame: 0x8f57ec40 0x2074
error frame: 0x8f57ec40 0x6f6f
boot> error frame: 0x8f57ec40 0x7465
error frame: 0x8f57ec80 0x7220
error frame: 0x8f57ec80 0x6374
error frame: 0x8f57ec80 0x7261
error frame: 0x8f57ec80 0x6f64
error frame: 0x8f57ec80 0x385f
error frame: 0x8f57ec80 0x2d31
error frame: 0x8f57ec80 0x6431
error frame: 0x8f57ec80 0x302d
error frame: 0x8f57ecc0 0x3233
error frame: 0x8f57ecc0 0x6e49
error frame: 0x8f57ecc0 0x6e6f
error frame: 0x8f57ecc0 0x7472
error frame: 0x8f57ecc0 0x622c
error frame: 0x8f57ecc0 0x6f6c
error frame: 0x8f57ecc0 0x3030
error frame: 0x8f57ecc0 0x3030
error frame: 0x8f57ed00 0x645f
error frame: 0x8f57ed00 0x6966
error frame: 0x8f57ed00 0x642f
error frame: 0x8f57ed00 0x6274
error frame: 0x8f57ed00 0x746e
error frame: 0x8f57ed00 0x6466
error frame: 0x8f57ed00 0x6d69
error frame: 0x8f57ed00 0x6f62
error frame: 0x8f57ed40 0x0062
error frame: 0x8f57ed40 0x463d
error frame: 0x8f57ed40 0x6461
error frame: 0x8f57ed40 0x3336
error frame: 0x8f57ed40 0x383a
error frame: 0x8f57ed40 0x7464
error frame: 0x8f57ed40 0x7830
error frame: 0x8f57ed40 0x3030
error frame: 0x8f57ed80 0x6464
error frame: 0x8f57ed80 0x3831
error frame: 0x8f57ed80 0x3d68
error frame: 0x8f57ed80 0x
error frame: 0x8f57ed80 0x6461
error frame: 0x8f57ed80 0x3030
error frame: 0x8f57ed80 0x6674
error frame: 0x8f57edc0 0x3678
error frame: 0x8f57edc0 0x2d78
error frame: 0x8f57edc0 0x6966
error frame: 0x8f57edc0 0x313d
error frame: 0x8f57edc0 0x0030
error frame: 0x8f57edc0 0x657a
error frame: 0x8f57edc0 0x693d
error frame: 0x8f57ee00 0x2420
error frame: 0x8f57ee00 0x616e
error frame: 0x8f57ee00 0x4d55
error frame: 0x8f57ee00 0x5241
error frame: 0x8f57ee00 0x6574
error frame: 0x8f57ee00 0x7261
error frame: 0x8f57ee00 0x203d
error frame: 0x8f57ee00 0x7420

booting sd0a:/bsd: 3926840+164812+561396|[283058+90+521360+245040]=0x571a54
Writing to MMC(0)... done

OpenBSD/armv7 booting ...
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] efi_loader: search all possible disk partitions

[Jonathan Gray]

On Tue, Oct 10, 2017 at 10:01:46AM +0200, Alexander Graf wrote:
> > When searching for partitions don't stop if a partition is not present
> > for a given partition number as there may be valid partitions after.
> > 
> > Search for up to MAX_SEARCH_PARTITIONS matching the other callers of
> > part_get_info().
> > 
> > This allows OpenBSD to boot via the efi_loader on rpi_3 again after
> > changes made after U-Boot 2017.09.  With MBR partitioning OpenBSD will
> > by default use the fourth partition for the 0xA6 (OpenBSD) partition.
> > 
> > Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> 
> Thanks, applied to efi-next
> 
> Alex
> 

Thanks, looking over it again I realised one of the loops is now
incrementing the partition number twice per loop so I have sent a
further patch to the list to correct that.
>From 18d6201e4e09b9e8d6bc418b23029280a29eb015 Mon Sep 17 00:00:00 2001
From: Jonathan Gray <j...@jsg.id.au>
Date: Tue, 10 Oct 2017 21:25:16 +1100
Subject: [PATCH] efi_loader: don't increment part twice per loop

Correct a mistake in the part number handling of
16a73b249d138fedeb188710533902ed7aac1ddc and only increment part once
per loop.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 lib/efi_loader/efi_disk.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 6b192701a8..e61dbc8058 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -360,7 +360,6 @@ int efi_disk_register(void)
continue;
efi_disk_add_dev(devname, if_typename, desc,
 i, 0, part);
-   part++;
}
 
/* ... and add block device: */
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] efi_loader: don't increment part twice per loop

[Jonathan Gray]

Correct a mistake in the part number handling of
16a73b249d138fedeb188710533902ed7aac1ddc and only increment part once
per loop.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 lib/efi_loader/efi_disk.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 6b192701a8..e61dbc8058 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -360,7 +360,6 @@ int efi_disk_register(void)
continue;
efi_disk_add_dev(devname, if_typename, desc,
 i, 0, part);
-   part++;
}
 
/* ... and add block device: */
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] efi_loader: search all possible disk partitions

[Jonathan Gray]

When searching for partitions don't stop if a partition is not present
for a given partition number as there may be valid partitions after.

Search for up to MAX_SEARCH_PARTITIONS matching the other callers of
part_get_info().

This allows OpenBSD to boot via the efi_loader on rpi_3 again after
changes made after U-Boot 2017.09.  With MBR partitioning OpenBSD will
by default use the fourth partition for the 0xA6 (OpenBSD) partition.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 lib/efi_loader/efi_disk.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 47b487aa30..6b192701a8 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -254,18 +254,19 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
 #if CONFIG_IS_ENABLED(ISO_PARTITION)
char devname[32] = { 0 }; /* dp->str is u16[32] long */
disk_partition_t info;
-   int part = 1;
+   int part;
 
if (desc->part_type != PART_TYPE_ISO)
return 0;
 
/* and devices for each partition: */
-   while (!part_get_info(desc, part, )) {
+   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+   if (part_get_info(desc, part, ))
+   continue;
snprintf(devname, sizeof(devname), "%s:%d", pdevname,
 part);
efi_disk_add_dev(devname, if_typename, desc, diskid,
 info.start, part);
-   part++;
disks++;
}
 
@@ -299,15 +300,16 @@ int efi_disk_register(void)
struct blk_desc *desc = dev_get_uclass_platdata(dev);
const char *if_typename = dev->driver->name;
disk_partition_t info;
-   int part = 1;
+   int part;
 
printf("Scanning disk %s...\n", dev->name);
 
/* add devices for each partition: */
-   while (!part_get_info(desc, part, )) {
+   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+   if (part_get_info(desc, part, ))
+   continue;
efi_disk_add_dev(dev->name, if_typename, desc,
 desc->devnum, 0, part);
-   part++;
}
 
/* ... and add block device: */
@@ -341,7 +343,7 @@ int efi_disk_register(void)
struct blk_desc *desc;
char devname[32] = { 0 }; /* dp->str is u16[32] long */
disk_partition_t info;
-   int part = 1;
+   int part;
 
desc = blk_get_devnum_by_type(if_type, i);
if (!desc)
@@ -353,7 +355,9 @@ int efi_disk_register(void)
 if_typename, i);
 
/* add devices for each partition: */
-   while (!part_get_info(desc, part, )) {
+   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+   if (part_get_info(desc, part, ))
+   continue;
efi_disk_add_dev(devname, if_typename, desc,
 i, 0, part);
part++;
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot