[U-Boot] [PATCH v2 1/2] imx: board: Add support for the K+P's kp_imx6q_tpc board

[Lukasz Majewski]

This commit provides support for Kieback & Peter GmbH IMX6Q based
TPC board.

U-boot console output:

U-Boot SPL 2018.05-rc1-5-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)
Trying to boot from MMC1

U-Boot 2018.05-rc1-5-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 37C
Reset cause: POR
Board: K+P KP_IMX6Q_TPC i.MX6Q
   Watchdog enabled
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Autoboot in 3 seconds

---

Changes in v2:
- Provide usbupd command to check for USB updates
- Drop DCD table DDR3 setup in favor of u-boot mainline
- Enable DDR3 calibration for iMX6Q
- Add boot log for a reference

Dependency:
- This board requires following patch for proper operation:
[U-Boot] [PATCH] ARM: mx6: ddr: Add write leveling correction code

Signed-off-by: Lukasz Majewski 
---
 arch/arm/mach-imx/mx6/Kconfig |  11 +
 board/k+p/kp_imx6q_tpc/Kconfig|  12 ++
 board/k+p/kp_imx6q_tpc/MAINTAINERS|   6 +
 board/k+p/kp_imx6q_tpc/Makefile   |  11 +
 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c | 302 ++
 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc_spl.c | 338 ++
 configs/kp_imx6q_tpc_defconfig|  42 
 include/configs/kp_imx6q_tpc.h| 141 +
 8 files changed, 863 insertions(+)
 create mode 100644 board/k+p/kp_imx6q_tpc/Kconfig
 create mode 100644 board/k+p/kp_imx6q_tpc/MAINTAINERS
 create mode 100644 board/k+p/kp_imx6q_tpc/Makefile
 create mode 100644 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c
 create mode 100644 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc_spl.c
 create mode 100644 configs/kp_imx6q_tpc_defconfig
 create mode 100644 include/configs/kp_imx6q_tpc.h

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index d4ce38db8d..aa6f5facbf 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -387,6 +387,16 @@ config TARGET_TBS2910
 config TARGET_TITANIUM
bool "titanium"
 
+config TARGET_KP_IMX6Q_TPC
+   bool "K+P KP_IMX6Q_TPC i.MX6 Quad"
+   select MX6QDL
+   select BOARD_LATE_INIT
+   select BOARD_EARLY_INIT_F
+   select SUPPORT_SPL
+   select DM
+   select DM_THERMAL
+   imply CMD_SPL
+
 config TARGET_TQMA6
bool "TQ Systems TQMa6 board"
select BOARD_LATE_INIT
@@ -493,6 +503,7 @@ source "board/tbs/tbs2910/Kconfig"
 source "board/tqc/tqma6/Kconfig"
 source "board/toradex/apalis_imx6/Kconfig"
 source "board/toradex/colibri_imx6/Kconfig"
+source "board/k+p/kp_imx6q_tpc/Kconfig"
 source "board/udoo/Kconfig"
 source "board/udoo/neo/Kconfig"
 source "board/wandboard/Kconfig"
diff --git a/board/k+p/kp_imx6q_tpc/Kconfig b/board/k+p/kp_imx6q_tpc/Kconfig
new file mode 100644
index 00..62e34978ec
--- /dev/null
+++ b/board/k+p/kp_imx6q_tpc/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_KP_IMX6Q_TPC
+
+config SYS_BOARD
+   default "kp_imx6q_tpc"
+
+config SYS_VENDOR
+   default "k+p"
+
+config SYS_CONFIG_NAME
+   default "kp_imx6q_tpc"
+
+endif
diff --git a/board/k+p/kp_imx6q_tpc/MAINTAINERS 
b/board/k+p/kp_imx6q_tpc/MAINTAINERS
new file mode 100644
index 00..6c4c8dd28e
--- /dev/null
+++ b/board/k+p/kp_imx6q_tpc/MAINTAINERS
@@ -0,0 +1,6 @@
+KP_IMX6Q_TPC BOARD
+M: Lukasz Majewski 
+S: Maintained
+F: board/k+p/kp_imx6q_tpc/
+F: include/configs/kp_imx6q_tpc.h
+F: configs/kp_imx6q_tpc_defconfig
diff --git a/board/k+p/kp_imx6q_tpc/Makefile b/board/k+p/kp_imx6q_tpc/Makefile
new file mode 100644
index 00..51cbd3e843
--- /dev/null
+++ b/board/k+p/kp_imx6q_tpc/Makefile
@@ -0,0 +1,11 @@
+#
+# Copyright (C) 2018 Lukasz Majewski 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y  := kp_imx6q_tpc_spl.o
+else
+obj-y  := kp_imx6q_tpc.o
+endif
diff --git a/board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c 
b/board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c
new file mode 100644
index 00..9a5b88029f
--- /dev/null
+++ b/board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c
@@ -0,0 +1,302 @@
+/*
+ * K+P iMX6Q KP_IMX6Q_TPC board configuration
+ *
+ * Copyright (C) 2018 Lukasz Majewski 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ENET_PAD_CTRL  \
+   (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm |  \
+PAD_CTL_HYS)
+
+#define I2C_PAD_CTRL   \
+   (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm |  \
+   PAD_CTL_HYS | PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+

[U-Boot] [PATCH v2 2/2] boot: script: The boot.scr file for K+P's boards

[Lukasz Majewski]

By using this file one can avoid cluttering .h file with u-boot
HUSH commands necessary for booting target device.

With such approach the commands are stored only in one place and can be
reused if needed.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Stefano Babic 

---

Changes in v2:
- None

 board/k+p/bootscripts/tpcboot.cmd | 96 +++
 1 file changed, 96 insertions(+)
 create mode 100644 board/k+p/bootscripts/tpcboot.cmd

diff --git a/board/k+p/bootscripts/tpcboot.cmd 
b/board/k+p/bootscripts/tpcboot.cmd
new file mode 100644
index 00..f6d59a1186
--- /dev/null
+++ b/board/k+p/bootscripts/tpcboot.cmd
@@ -0,0 +1,96 @@
+#
+# Copyright (C) 2018
+# Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+#
+#
+# This is an example file to generate boot.scr - a boot script for U-Boot
+# Generate boot.scr:
+# ./tools/mkimage -c none -A arm -T script -d tpcboot.cmd boot.scr
+#
+# SPDX-License-Identifier: GPL-2.0+
+
+
+# Input envs (to be set in environment)
+# Mandatory:
+# kernel_file = "fitImage"
+# boardname = ""  // set automatically in u-boot
+# boardsoc = "imx6q"  // set automatically in u-boot
+#
+# Optional:
+# bootcmd_force = "nfs" "tftp_kernel"
+# If not set - eMMC/SD boot
+
+# Generic setup
+setenv mmcroot "/dev/mmcblk${devnum}p2 rootwait rw"
+setenv displayargs ""
+setenv mmcargs "setenv bootargs console=${console} ${smp} root=${mmcroot} \
+   ${displayargs}"
+setenv boot_fitImage "
+   setenv fdt_conf 'conf@${boardsoc}-${boardname}.dtb';
+   setenv itbcfg "\"#\${fdt_conf}\"";
+   print itbcfg;
+   bootm '${loadaddr}${itbcfg}';"
+
+#
+#
+# Provide default 'bootcmd' command
+#
+setenv bootcmd "
+if test -e ${devtype} ${devnum}:${distro_bootpart} ${kernel_file}; then
+   echo Found kernel image: ${kernel_file};
+   if load ${devtype} ${devnum}:${distro_bootpart} ${loadaddr} \
+  ${kernel_file}; then
+   run mmcargs;
+   run boot_fitImage;
+   fi;
+fi;"
+
+#
+#
+# Provide 'boot_tftp_kernel' command
+#
+setenv download_kernel "tftpboot ${loadaddr} ${kernel_file}"
+
+setenv boot_tftp_kernel "
+if run download_kernel; then
+   run mmcargs;
+   run boot_fitImage;
+fi"
+
+#
+#
+# Provide 'boot_nfs' command
+#
+setenv rootpath "/srv/tftp/KP/rootfs"
+setenv nfsargs "setenv bootargs root=/dev/nfs rw \
+   nfsroot=${serverip}:${rootpath},nolock,nfsvers=3"
+setenv addip "setenv bootargs ${bootargs} \
+   ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:\
+   ${hostname}:eth0:on"
+
+setenv boot_nfs "
+if run download_kernel; then
+   run nfsargs;
+   run addip;
+   setenv bootargs ${bootargs} console=${console};
+
+   run boot_fitImage;
+fi"
+
+#
+#
+# Set correct boot flow
+#
+
+setenv bcmd "
+if test ! -n ${bootcmd_force}; then
+   run bootcmd;
+fi;
+if test ${bootcmd_force} = nfs; then
+   run boot_nfs;
+else if test ${bootcmd_force} = tftp_kernel; then
+   run boot_tftp_kernel;
+ fi;
+fi"
+
+run bcmd
-- 
2.11.0

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

Re: [U-Boot] [PATCH v2 1/3] efi_loader: allow unaligned memory access

[Alexander Graf]

On 04/04/2018 09:14 PM, Heinrich Schuchardt wrote:

On 04/04/2018 06:11 PM, Alexander Graf wrote:


On 04.04.18 17:10, Heinrich Schuchardt wrote:

On 04/04/2018 02:32 PM, Alexander Graf wrote:


On 03.04.18 21:59, Heinrich Schuchardt wrote:

The UEFI spec mandates that unaligned memory access should be enabled if
supported by the CPU architecture.

This patch adds an empty weak function unaligned_access() that can be
overridden by an architecture specific routine.

Signed-off-by: Heinrich Schuchardt 
---
  cmd/bootefi.c   | 13 +
  include/asm-generic/unaligned.h |  3 +++
  2 files changed, 16 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ba258ac9f3..412e6519ba 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  DECLARE_GLOBAL_DATA_PTR;

@@ -89,6 +90,15 @@ out:
return ret;
  }
  
+/*

+ * Allow unaligned memory access.
+ *
+ * This routine is overridden by architectures providing this feature.
+ */
+void __weak allow_unaligned(void)
+{
+}
+

I'd prefer to guard the body of the function with an #ifdef CONFIG_ARM
so everyone knows why it's there. Then call straight into a function
provided in the ARM core code:

The same visibility can be achieved with a comment.

It's not as obvious. The default really should be to map memory as
cached and allow for unaligned accesses.


static void allow_unaligned(void)
{
/* On ARM we prohibit unaligned accesses by default, enable them here */
#if defined(CONFIG_ARM) && !defined(CONFIG_ARM64) &&
!defined(CONFIG_CPU_V7M)
   mmu_enable_unaligned();
#endif
}

RISC-V also supports traps for unaligned access.

Just because it supports them doesn't mean we should use them. AArch64
also allows for unaligned access traps and I went through great length
to refactor the mm code in U-Boot to ensure that we do not trap.


Using architecture specific flags outside arch/ is a mess.
We should not commit new sins but eliminate the existing deviations.


And then in arch/arm/lib/cache-cp15.c:

void mmu_enable_unaligned(void)
{
   set_cr(get_cr() & ~CR_A);
}

For some ARM architecture versions the bit is reserved and not used for
unaligned access. No clue what this function would do in this case.

Do you have pointers? Anything defined in the UEFI spec should have the bit.

UEFI spec 2.7:
2.3.5 AArch32 Platforms
In addition, the invoking OSs can assume that unaligned access support
is enabled if it is present in the processor.

So the UEFI spec foresees processors supporting unaligned memory access
and others that do not support it.


I think the only corner case is Cortex-M, but that's not terribly high 
up on my priority list. And if that requires everything to be aligned, 
so be it.





That is why I used a weak function that does nothing if the CPU does not
support the flag.

Any platform that uses cache-cp15 also supports the CR_A bit FWIW. So it
really belongs there.>
And again, I do not want to prettify a special hack for a broken
architecture. People should see warts when they're there.

The real fix IMHO is to enable aligned accesses always, like we do on
any sane architecture.


Is this a typo: "enable aligned accesses"?

Aligned access is always enabled. It is unaligned access that currently
is not enabled in U-Boot.


Yes, enable unaligned accesses of course :).

Albert, this is your call I think. Would you be heavily opposed to 
Heinrich's initial patch? It really is the best option IMHO:


  https://patchwork.ozlabs.org/patch/893014/


Alex

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

Re: [U-Boot] [PATCH v3 2/2] arm: print information about loaded UEFI images

[Alexander Graf]

On 04/04/2018 04:36 PM, Heinrich Schuchardt wrote:

If an exception occurs in a UEFI loaded image we need the start address of
the image to determine the relocation offset.

This patch adds the necessary lines after the registers in the crash dump.
A possible output would be:

UEFI image [0xbffe6000:0xbffe631f] pc=0x138 '/\snp.efi'

With the offset 0x138 we can now find the relevant instruction in the
disassembled 'snp.efi' binary.

Signed-off-by: Heinrich Schuchardt 
---
  arch/arm/lib/interrupts.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index 80869adb61..dad77ff589 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -20,6 +20,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -51,6 +52,14 @@ void bad_mode (void)
reset_cpu (0);
  }
  
+static void show_efi_loaded_images(struct pt_regs *regs)

+{
+#if defined(CONFIG_EFI_LOADER) && \
+   !defined(CONFIG_SPL_BUILD) && !defined(API_BUILD)
+   efi_print_image_infos((void *)instruction_pointer(regs));
+#endif


Sorry I didn't catch this earlier. Please just implement a stub function 
in include/efi_loader.h, similar to efi_set_bootdev() for example. That 
way we keep the generic code clean from ifdefs.


Also, why do you have to exclude API_BUILD?


Alex


+}
+
  void show_regs (struct pt_regs *regs)
  {
unsigned long __maybe_unused flags;
@@ -106,6 +115,7 @@ void do_undefined_instruction (struct pt_regs *pt_regs)
printf ("undefined instruction\n");
fixup_pc(pt_regs, -4);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
  }
  
@@ -115,6 +125,7 @@ void do_software_interrupt (struct pt_regs *pt_regs)

printf ("software interrupt\n");
fixup_pc(pt_regs, -4);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
  }
  
@@ -124,6 +135,7 @@ void do_prefetch_abort (struct pt_regs *pt_regs)

printf ("prefetch abort\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
  }
  
@@ -133,6 +145,7 @@ void do_data_abort (struct pt_regs *pt_regs)

printf ("data abort\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
  }
  
@@ -142,6 +155,7 @@ void do_not_used (struct pt_regs *pt_regs)

printf ("not used\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
  }
  
@@ -151,6 +165,7 @@ void do_fiq (struct pt_regs *pt_regs)

printf ("fast interrupt request\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
  }
  
@@ -160,5 +175,6 @@ void do_irq (struct pt_regs *pt_regs)

printf ("interrupt request\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
  }



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

[U-Boot] [PATCH] rpi: Allow to boot without serial

[Alexander Graf]

When we enable CONFIG_OF_BOARD on Raspberry Pis, we may end up without
serial console support in early boot. Hence we need to make the serial
port optional, otherwise we will never get to the point where serial
would be probed.

Signed-off-by: Alexander Graf 
---
 configs/rpi_0_w_defconfig | 1 +
 configs/rpi_2_defconfig   | 1 +
 configs/rpi_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 04717d5e50..6e02cf34e9 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -34,3 +34,4 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_REQUIRE_SERIAL_CONSOLE is not set
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index f8203c9d47..dd3c60cc93 100644
--- a/configs/rpi_2_defconfig
+++ b/configs/rpi_2_defconfig
@@ -34,3 +34,4 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_REQUIRE_SERIAL_CONSOLE is not set
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
index d13d3d3e2e..2c0412d8ea 100644
--- a/configs/rpi_defconfig
+++ b/configs/rpi_defconfig
@@ -34,3 +34,4 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_REQUIRE_SERIAL_CONSOLE is not set
-- 
2.12.3

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

Re: [U-Boot] [U-Boot,1/2] rpi3: Enable lan78xx driver

[Alexander Graf]

> The new Raspberry Pi B 3+ has a lan78xx device attached to it. Let's add
> driver support in U-Boot for it.
> 
> Signed-off-by: Alexander Graf 

Thanks, applied to efi-next

Alex

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

Re: [U-Boot] rpi3_32b: Enable lan78xx driver

[Alexander Graf]

> The new Raspberry Pi B 3+ has a lan78xx device attached to it. Let's add
> driver support in U-Boot for it.
> 
> Signed-off-by: Peter Robinson 

Thanks, applied to efi-next

Alex

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

Re: [U-Boot] [U-Boot,2/2] rpi: Add identifier for the new RPi3 B+

[Alexander Graf]

> The Raspberr Pi Foundation released a new RPi3 version which we want
> to detect as well, so we can enable ethernet on it and know the correct
> device tree file name.
> 
> Add an identifier for it.
> 
> Signed-off-by: Alexander Graf 

Thanks, applied to efi-next

Alex

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

[U-Boot] [PATCH v4 2/2] arm: print information about loaded UEFI images

[Heinrich Schuchardt]

If an exception occurs in a UEFI loaded image we need the start address of
the image to determine the relocation offset.

This patch adds the necessary lines after the registers in the crash dump.
A possible output would be:

UEFI image [0xbffe6000:0xbffe631f] pc=0x138 '/\snp.efi'

With the offset 0x138 we can now find the relevant instruction in the
disassembled 'snp.efi' binary.

Signed-off-by: Heinrich Schuchardt 
---
v4:
remove ifdefs, we have a stub function now
---
 arch/arm/lib/interrupts.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index 80869adb61..cda4d48460 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -20,6 +20,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,11 @@ void bad_mode (void)
reset_cpu (0);
 }
 
+static void show_efi_loaded_images(struct pt_regs *regs)
+{
+   efi_print_image_infos((void *)instruction_pointer(regs));
+}
+
 void show_regs (struct pt_regs *regs)
 {
unsigned long __maybe_unused flags;
@@ -106,6 +112,7 @@ void do_undefined_instruction (struct pt_regs *pt_regs)
printf ("undefined instruction\n");
fixup_pc(pt_regs, -4);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -115,6 +122,7 @@ void do_software_interrupt (struct pt_regs *pt_regs)
printf ("software interrupt\n");
fixup_pc(pt_regs, -4);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -124,6 +132,7 @@ void do_prefetch_abort (struct pt_regs *pt_regs)
printf ("prefetch abort\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -133,6 +142,7 @@ void do_data_abort (struct pt_regs *pt_regs)
printf ("data abort\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -142,6 +152,7 @@ void do_not_used (struct pt_regs *pt_regs)
printf ("not used\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -151,6 +162,7 @@ void do_fiq (struct pt_regs *pt_regs)
printf ("fast interrupt request\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -160,5 +172,6 @@ void do_irq (struct pt_regs *pt_regs)
printf ("interrupt request\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
-- 
2.16.3

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

[U-Boot] [PATCH v4 0/2] efi_loader: print information about loaded UEFI images

[Heinrich Schuchardt]

If a crash occurs the relocation information of loaded EFI images is
displayed.

---
v4
Remove merged patches.
Avoid ifdefs by using a stub function.
v3
Remove merged patches.
Change the output format for loaded images.
v2
Merge with "efi_loader: print information about loaded UEFI images"
patch series.

GRUB does not allow the relocated address to be used as ImageBase
in the loaded image information. So the relocation address has to
be stored in an additional field.
---
Heinrich Schuchardt (2):
  efi_loader: new functions to print loaded image information
  arm: print information about loaded UEFI images

 arch/arm/lib/interrupts.c | 13 +++
 include/efi_loader.h  |  5 +
 lib/efi_loader/efi_image_loader.c | 46 +++
 3 files changed, 64 insertions(+)

-- 
2.16.3

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

[U-Boot] [PATCH v4 1/2] efi_loader: new functions to print loaded image information

[Heinrich Schuchardt]

Introduce functions to print information about loaded images.

If we want to analyze an exception in an EFI image we need the offset
between the PC and the start of the loaded image.

With efi_print_image_info() we can print the necessary information for a
single image, e.g.

UEFI image [0xbffe6000:0xbffe631f] pc=0x138 '/\snp.efi'

efi_print_image_infos() provides output for all loaded images.

Signed-off-by: Heinrich Schuchardt 
---
v4
add stub for efi_print_image_infos()
v3
condense output per image to one line
---
 include/efi_loader.h  |  5 +
 lib/efi_loader/efi_image_loader.c | 46 +++
 2 files changed, 51 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index f2942fbb2b..17f9d3d1ef 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -308,6 +308,10 @@ efi_status_t efi_setup_loaded_image(
struct efi_device_path *file_path);
 efi_status_t efi_load_image_from_path(struct efi_device_path *file_path,
  void **buffer);
+/* Print information about a loaded image */
+efi_status_t efi_print_image_info(struct efi_loaded_image *image, void *pc);
+/* Print information about all loaded images */
+void efi_print_image_infos(void *pc);
 
 #ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
 extern void *efi_bounce_buffer;
@@ -425,6 +429,7 @@ static inline void efi_restore_gd(void) { }
 static inline void efi_set_bootdev(const char *dev, const char *devnr,
   const char *path) { }
 static inline void efi_net_set_dhcp_ack(void *pkt, int len) { }
+static inline void efi_print_image_infos(void *pc) { }
 
 #endif /* CONFIG_EFI_LOADER && !CONFIG_SPL_BUILD */
 
diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index 74c6a9f921..f5885760d4 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -22,6 +22,52 @@ const efi_guid_t efi_simple_file_system_protocol_guid =
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
 const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
 
+/*
+ * Print information about a loaded image.
+ *
+ * If the program counter is located within the image the offset to the base
+ * address is shown.
+ *
+ * @image: loaded image
+ * @pc:program counter (use NULL to suppress offset output)
+ * @return:status code
+ */
+efi_status_t efi_print_image_info(struct efi_loaded_image *image, void *pc)
+{
+   if (!image)
+   return EFI_INVALID_PARAMETER;
+   printf("UEFI image");
+   printf(" [0x%p:0x%p]",
+  image->reloc_base, image->reloc_base + image->reloc_size - 1);
+   if (pc && pc >= image->reloc_base &&
+   pc < image->reloc_base + image->reloc_size)
+   printf(" pc=0x%zx", pc - image->reloc_base);
+   if (image->file_path)
+   printf(" '%pD'", image->file_path);
+   printf("\n");
+   return EFI_SUCCESS;
+}
+
+/*
+ * Print information about all loaded images.
+ *
+ * @pc:program counter (use NULL to suppress offset output)
+ */
+void efi_print_image_infos(void *pc)
+{
+   struct efi_object *efiobj;
+   struct efi_handler *handler;
+
+   list_for_each_entry(efiobj, &efi_obj_list, link) {
+   list_for_each_entry(handler, &efiobj->protocols, link) {
+   if (!guidcmp(handler->guid, &efi_guid_loaded_image)) {
+   efi_print_image_info(
+   handler->protocol_interface, pc);
+   }
+   }
+   }
+}
+
 static efi_status_t efi_loader_relocate(const IMAGE_BASE_RELOCATION *rel,
unsigned long rel_size, void *efi_reloc)
 {
-- 
2.16.3

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

Re: [U-Boot] [PATCH v3 03/15] env: Pass additional parameters to the env lookup function

[Simon Goldschmidt]

Sorry to warm up this old thread, but I think the implementation of 
env_save does not really work on error:


On my board, I have the environment stored in QSPI. If saving fails, 
env_save tries to continue to the next environment driver, but 
env_driver_lookup/env_get_location always returns the same driver for 
ENVOP_SAVE (gd->env_load_location).


The result is that if the env driver returns an error from its save 
function, env_save hangs in an infinite loop.

Sorry I don't have a patch for this right now...

Simon

On 23.01.2018 21:16, Maxime Ripard wrote:

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard 
---
  env/env.c | 157 +--
  include/environment.h |   8 ++-
  2 files changed, 116 insertions(+), 49 deletions(-)

diff --git a/env/env.c b/env/env.c
index 97ada5b5a6fd..73da149fd8ca 100644
--- a/env/env.c
+++ b/env/env.c
@@ -26,8 +26,33 @@ static struct env_driver *_env_driver_lookup(enum 
env_location loc)
return NULL;
  }
  
-static enum env_location env_get_location(void)

+/**
+ * env_get_location() - Returns the best env location for a board
+ * @op: operations performed on the environment
+ * @prio: priority between the multiple environments, 0 being the
+ *highest priority
+ *
+ * This will return the preferred environment for the given priority.
+ *
+ * All implementations are free to use the operation, the priority and
+ * any other data relevant to their choice, but must take into account
+ * the fact that the lowest prority (0) is the most important location
+ * in the system. The following locations should be returned by order
+ * of descending priorities, from the highest to the lowest priority.
+ *
+ * Returns:
+ * an enum env_location value on success, a negative error code otherwise
+ */
+static enum env_location env_get_location(enum env_operation op, int prio)
  {
+   /*
+* We support a single environment, so any environment asked
+* with a priority that is not zero is out of our supported
+* bounds.
+*/
+   if (prio >= 1)
+   return ENVL_UNKNOWN;
+
if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
return ENVL_EEPROM;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
@@ -52,11 +77,27 @@ static enum env_location env_get_location(void)
return ENVL_UNKNOWN;
  }
  
-static struct env_driver *env_driver_lookup(void)

+
+/**
+ * env_driver_lookup() - Finds the most suited environment location
+ * @op: operations performed on the environment
+ * @prio: priority between the multiple environments, 0 being the
+ *highest priority
+ *
+ * This will try to find the available environment with the highest
+ * priority in the system.
+ *
+ * Returns:
+ * NULL on error, a pointer to a struct env_driver otherwise
+ */
+static struct env_driver *env_driver_lookup(enum env_operation op, int prio)
  {
-   enum env_location loc = env_get_location();
+   enum env_location loc = env_get_location(op, prio);
struct env_driver *drv;
  
+	if (loc == ENVL_UNKNOWN)

+   return NULL;
+
drv = _env_driver_lookup(loc);
if (!drv) {
debug("%s: No environment driver for location %d\n", __func__,
@@ -69,83 +110,101 @@ static struct env_driver *env_driver_lookup(void)
  
  int env_get_char(int index)

  {
-   struct env_driver *drv = env_driver_lookup();
-   int ret;
+   struct env_driver *drv;
+   int prio;
  
  	if (gd->env_valid == ENV_INVALID)

return default_environment[index];
-   if (!drv)
-   return -ENODEV;
-   if (!drv->get_char)
-   return *(uchar *)(gd->env_addr + index);
-   ret = drv->get_char(index);
-   if (ret < 0) {
-   debug("%s: Environment failed to load (err=%d)\n",
- __func__, ret);
+
+   for (prio = 0; (drv = env_driver_lookup(ENVOP_GET_CHAR, prio)); prio++) 
{
+   int ret;
+
+   if (!drv->get_char)
+   continue;
+
+   ret = drv->get_char(index);
+   if (!ret)
+   return 0;
+
+  

Re: [U-Boot] [PATCH] x86: Use microcode update from device tree for all processors

[Andy Shevchenko]

On Wed, 2018-04-04 at 16:07 -0700, Ivan Gorinov wrote:
> The microcode update data block encoded in Device Tree is used by
> the bootstrap processor (BSP) but not passed to the other CPUs (AP).

BSP abbreviation is confusing. AP is even more looking to preceding
words. I don't see either where they are used.

> If the bootstrap processor successfully performs a microcode update
> from Device Tree, use the same data block for the other processors.
> 

>  #include 
>  #include 
>  #include 
> +#include 

Keep it in order.

>  #include 

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Alexander Graf]

> 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 
> Cc: Alexander Graf 
> Cc: Peter Robinson 

Thanks, applied to rpi-next

Alex

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

Re: [U-Boot] [PATCH v2 1/2] SPI Flash: add support of sst26wf* flash series

[Eugeniy Paltsev]

On Wed, 2018-04-04 at 19:58 +0530, Jagan Teki wrote:
> On Mon, Mar 26, 2018 at 4:38 PM, Eugeniy Paltsev
>  wrote:
> > sst26wf flash series block protection implementation differs
> > from other SST series, so add implementation for sst26wf
> > lock/unlock/is_locked functions.
[snip]
> > 
> > +/* sst26wf series block protection implementation differs from other 
> > series */
> > +#if defined(CONFIG_SPI_FLASH_SST)
> > +   if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST &&
> > +   (JEDEC_ID(info) >> 8) == 0x26) {
> 
> You can directly use JEDEC_ID that may cover id[0], id[1]? or does
> this only for id[0]?

It is only for "JEDEC Device Type Byte" (byte 1) == 0x26;
"Device ID Byte" (byte 2) can be any.

But I can write it like
  (info->id[1] == 0x26)
instead of
  ((JEDEC_ID(info) >> 8) == 0x26)

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

Re: [U-Boot] [PATCH v2 1/2] SPI Flash: add support of sst26wf* flash series

[Jagan Teki]

On Thu, Apr 5, 2018 at 6:10 PM, Eugeniy Paltsev
 wrote:
> On Wed, 2018-04-04 at 19:58 +0530, Jagan Teki wrote:
>> On Mon, Mar 26, 2018 at 4:38 PM, Eugeniy Paltsev
>>  wrote:
>> > sst26wf flash series block protection implementation differs
>> > from other SST series, so add implementation for sst26wf
>> > lock/unlock/is_locked functions.
> [snip]
>> >
>> > +/* sst26wf series block protection implementation differs from other 
>> > series */
>> > +#if defined(CONFIG_SPI_FLASH_SST)
>> > +   if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST &&
>> > +   (JEDEC_ID(info) >> 8) == 0x26) {
>>
>> You can directly use JEDEC_ID that may cover id[0], id[1]? or does
>> this only for id[0]?
>
> It is only for "JEDEC Device Type Byte" (byte 1) == 0x26;
> "Device ID Byte" (byte 2) can be any.
>
> But I can write it like
>   (info->id[1] == 0x26)
> instead of
>   ((JEDEC_ID(info) >> 8) == 0x26)

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

Re: [U-Boot] [U-Boot, 18/36] rockchip: rk3188: remove rockchip timer as sys timer

[Heiko Stuebner]

Am Montag, 2. April 2018, 11:51:30 CEST schrieb Dr. Philipp Tomsich:
> Arturri,
> 
> > On 2 Apr 2018, at 11:38, Artturi Alm  wrote:
> > 
> > On Sun, Apr 01, 2018 at 10:21:50PM +0200, Philipp Tomsich wrote:
> >>> We use ARM arch timer instead.
> >>> 
> >>> Signed-off-by: Kever Yang 
> >>> ---
> >>> 
> >>> include/configs/rk3188_common.h | 3 ---
> >>> 1 file changed, 3 deletions(-)
> >>> 
> >> 
> >> Acked-by: Philipp Tomsich 
> > 
> > fwiw., i don't believe rk3188(Cortex-A9) has the armv7 'arch timer'.
> > please do test before applying..
> 
> I won’t be able to test this one (and a number other ones), as I only
> have access to RK3399 and RK3368 boards.
> 
> Feel free to validate this on your end and comment on this patch.
> 
> This patch set is not on my list for the current release cycle, due to
> it affecting all boards and the associated test effort needed.  I am
> considering either for a ‘next’-branch or for a topic-branch to be
> created later in this cycle (e.g. branched off rc2?).

Cortex-A9 socs like the rk3188 (and rk3066) do not have an
architected timer. That was only introduced with the following
ARM cores. So the timer support should probably stay around


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

Re: [U-Boot] [PATCHv2 1/6] reset: socfpga: add reset driver for SoCFPGA platform

[Dinh Nguyen]

v

On 04/04/2018 05:56 PM, Marek Vasut wrote:
> On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
>> Add a DM compatible reset driver for the SoCFPGA platform.
>>
>> Signed-off-by: Dinh Nguyen 
> 
> [...]
> 
>> +static int socfpga_reset_request(struct reset_ctl *reset_ctl)
>> +{
>> +debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__,
>> +  reset_ctl, reset_ctl->dev, reset_ctl->id);
>> +
>> +return 0;
>> +}
>> +
>> +static int socfpga_reset_free(struct reset_ctl *reset_ctl)
>> +{
>> +debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
>> +  reset_ctl->dev, reset_ctl->id);
>> +
>> +return 0;
>> +}
> 
> Is request/free needed at all ? It looks like a useless debug to me.
> 

I used the code to debug that the i2c driver did hook into the reset
manager driver. Certainly, it can be removed in the final version. I'll
send a V3 shortly with this removed.

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

Re: [U-Boot] [PATCHv2 1/6] reset: socfpga: add reset driver for SoCFPGA platform

[Dinh Nguyen]

On 04/05/2018 09:12 AM, Dinh Nguyen wrote:
> v
> 
> On 04/04/2018 05:56 PM, Marek Vasut wrote:
>> On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
>>> Add a DM compatible reset driver for the SoCFPGA platform.
>>>
>>> Signed-off-by: Dinh Nguyen 
>>
>> [...]
>>
>>> +static int socfpga_reset_request(struct reset_ctl *reset_ctl)
>>> +{
>>> +   debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__,
>>> + reset_ctl, reset_ctl->dev, reset_ctl->id);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int socfpga_reset_free(struct reset_ctl *reset_ctl)
>>> +{
>>> +   debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
>>> + reset_ctl->dev, reset_ctl->id);
>>> +
>>> +   return 0;
>>> +}
>>
>> Is request/free needed at all ? It looks like a useless debug to me.
>>
> 
> I used the code to debug that the i2c driver did hook into the reset
> manager driver. Certainly, it can be removed in the final version. I'll
> send a V3 shortly with this removed.
> 

I cannot remove the request function as this is needed in the
reset-uclass driver. Do you want me to remove free? Leaving the code
there seems harmless to me.

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

Re: [U-Boot] [PATCH] driver: net: fsl-mc: updated copyright info

[York Sun]

On 03/15/2018 12:07 AM, Yogesh Narayan Gaur wrote:
> Updated copyright info for the issues reported after running
> check-legal test.
> 
> Signed-off-by: Yogesh Gaur 
> ---
> Legally NXP and Freescale Semiconductor are same entity.
>  drivers/net/fsl-mc/dpbp.c  | 2 +-
>  drivers/net/fsl-mc/dpio/dpio.c | 2 +-
>  drivers/net/fsl-mc/dpmac.c | 2 +-
>  drivers/net/fsl-mc/dpni.c  | 2 +-
>  drivers/net/fsl-mc/dprc.c  | 2 +-
>  drivers/net/fsl-mc/fsl_dpmng_cmd.h | 2 +-
>  drivers/net/fsl-mc/mc.c| 4 ++--
>  drivers/net/ldpaa_eth/ldpaa_eth.c  | 2 +-
>  drivers/net/ldpaa_eth/ldpaa_eth.h  | 2 +-
>  include/fsl-mc/fsl_dpbp.h  | 2 +-
>  include/fsl-mc/fsl_dpio.h  | 2 +-
>  include/fsl-mc/fsl_dpmac.h | 2 +-
>  include/fsl-mc/fsl_dpni.h  | 2 +-
>  include/fsl-mc/fsl_dprc.h  | 2 +-
>  include/fsl-mc/fsl_mc_cmd.h| 2 +-
>  include/fsl-mc/fsl_mc_private.h| 2 +-
>  16 files changed, 17 insertions(+), 17 deletions(-)
> 

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

[U-Boot] [PATCH v3 0/2] SF: add support for sst26wf016, sst26wf032, sst26wf064

[Eugeniy Paltsev]

Add support for the SST sst26wf016, sst26wf032 and sst26wf064 flash IC:

sst26wf*** flash series block protection implementation differs from other
SST series, so we add implementation for sst26wf*** lock/unlock/is_locked
functions.

Add sst26wf016, sst26wf032 and sst26wf064 flash IC info to spi_flash_ids list.

Changes v2->v3:
 * Move SST26 command defenition to sf_internal.h
 * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
   into single sst26_process_bpr function.
 * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
   sst26_lock_ctl()

Changes v1->v2:
 * Use generic defines from linux/sizes.h instead of custom ones.

Eugeniy Paltsev (2):
  SPI Flash: add support of sst26wf* flash ICs protection ops
  SF: add support for sst26wf016, sst26wf032, sst26wf064

 drivers/mtd/spi/sf_internal.h   |  18 +
 drivers/mtd/spi/spi_flash.c | 165 
 drivers/mtd/spi/spi_flash_ids.c |   3 +
 3 files changed, 186 insertions(+)

-- 
2.14.3

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

[U-Boot] [PATCH v3 2/2] SF: add support for sst26wf016, sst26wf032, sst26wf064

[Eugeniy Paltsev]

This commit adds support for the SST sst26wf016, sst26wf032
and sst26wf064 flash IC.

Signed-off-by: Eugeniy Paltsev 
---
Changes v2->v3:
 * None.

Changes v1->v2:
 * None.

 drivers/mtd/spi/spi_flash_ids.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index b789219e4e..dbb4ac4d32 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -151,6 +151,9 @@ const struct spi_flash_info spi_flash_ids[] = {
{"sst25wf040", INFO(0xbf2504, 0x0,  64 * 1024, 8, SECT_4K | 
SST_WR) },
{"sst25wf040b",INFO(0x621613, 0x0,  64 * 1024, 8, SECT_4K) },
{"sst25wf080", INFO(0xbf2505, 0x0,  64 * 1024,16, SECT_4K | 
SST_WR) },
+   {"sst26wf016", INFO(0xbf2651, 0x0,  64 * 1024,32, SECT_4K) },
+   {"sst26wf032", INFO(0xbf2622, 0x0,  64 * 1024,64, SECT_4K) },
+   {"sst26wf064", INFO(0xbf2643, 0x0,  64 * 1024,   128, SECT_4K) },
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
{"w25p80", INFO(0xef2014, 0x0,  64 * 1024,16, 0) },
-- 
2.14.3

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

[U-Boot] [PATCH v3 1/2] SPI Flash: add support of sst26wf* flash ICs protection ops

[Eugeniy Paltsev]

sst26wf flash series block protection implementation differs
from other SST series, so add specific implementation
flash_lock/flash_unlock/flash_is_locked functions for sst26wf
flash ICs.

Signed-off-by: Eugeniy Paltsev 
---
Changes v2->v3:
 * Move SST26 command defenition to sf_internal.h
 * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
   into single sst26_process_bpr function.
 * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
   sst26_lock_ctl()

Changes v1->v2:
 * Use generic defines from linux/sizes.h instead of custom ones.

 drivers/mtd/spi/sf_internal.h |  18 +
 drivers/mtd/spi/spi_flash.c   | 165 ++
 2 files changed, 183 insertions(+)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 839cdbe1b0..a17dcc4de1 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -26,6 +26,11 @@ enum spi_nor_option_flags {
SNOR_F_USE_UPAGE= BIT(3),
 };
 
+enum flash_lock_status {
+   SF_UNLOCKED = 0,
+   SF_LOCKED   = 1,
+};
+
 #define SPI_FLASH_3B_ADDR_LEN  3
 #define SPI_FLASH_CMD_LEN  (1 + SPI_FLASH_3B_ADDR_LEN)
 #define SPI_FLASH_16MB_BOUN0x100
@@ -87,6 +92,19 @@ enum spi_nor_option_flags {
 
 /* SST specific */
 #ifdef CONFIG_SPI_FLASH_SST
+#define SST26_CMD_READ_BPR 0x72
+#define SST26_CMD_WRITE_BPR0x42
+
+#define SST26_BPR_8K_NUM   4
+#define SST26_MAX_BPR_REG_LEN  (18 + 1)
+#define SST26_BOUND_REG_SIZE   ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
+
+enum lock_ctl {
+   CTL_LOCK,
+   CTL_UNLOCK,
+   CTL_CHECK
+};
+
 # define CMD_SST_BP0x02/* Byte Program */
 # define CMD_SST_AAI_WP0xAD/* Auto Address Incr Word 
Program */
 
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 2e61685d3e..376753b6aa 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sf_internal.h"
@@ -842,6 +843,161 @@ int stm_unlock(struct spi_flash *flash, u32 ofs, size_t 
len)
 }
 #endif
 
+#if defined(CONFIG_SPI_FLASH_SST)
+bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl ctl)
+{
+   switch (ctl) {
+   case CTL_LOCK:
+   cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
+   break;
+   case CTL_UNLOCK:
+   cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
+   break;
+   case CTL_CHECK:
+   return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
+   }
+
+   return false;
+}
+
+/*
+ * sst26wf016/sst26wf032/sst26wf064 have next block protection:
+ * 4x   - 8  KByte blocks - read & write protection bits - upper addresses
+ * 1x   - 32 KByte blocks - write protection bits
+ * rest - 64 KByte blocks - write protection bits
+ * 1x   - 32 KByte blocks - write protection bits
+ * 4x   - 8  KByte blocks - read & write protection bits - lower addresses
+ *
+ * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
+ * will be treated as single block.
+ */
+
+/*
+ * Lock, unlock or check lock status of the flash region of the flash 
(depending
+ * on the lock_ctl value)
+ */
+int sst26_lock_ctl(struct spi_flash *flash, u32 ofs, size_t len, enum lock_ctl 
ctl)
+{
+   u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
+   bool lower_64k = false, upper_64k = false;
+   u8 cmd, bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
+   int ret;
+
+   /* Check length and offset for 64k alignment */
+   if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1)))
+   return -EINVAL;
+
+   if (ofs + len > flash->size)
+   return -EINVAL;
+
+   /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
+   if (flash->size != SZ_2M &&
+   flash->size != SZ_4M &&
+   flash->size != SZ_8M)
+   return -EINVAL;
+
+   bpr_size = 2 + (flash->size / SZ_64K / 8);
+
+   cmd = SST26_CMD_READ_BPR;
+   ret = spi_flash_read_common(flash, &cmd, 1, bpr_buff, bpr_size);
+   if (ret < 0) {
+   printf("SF: fail to read block-protection register\n");
+   return ret;
+   }
+
+   rptr_64k = min_t(u32, ofs + len , flash->size - SST26_BOUND_REG_SIZE);
+   lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
+
+   upper_64k = ((ofs + len) > (flash->size - SST26_BOUND_REG_SIZE));
+   lower_64k = (ofs < SST26_BOUND_REG_SIZE);
+
+   /* Lower bits in block-protection register are about 64k region */
+   bpr_ptr = lptr_64k / SZ_64K - 1;
+
+   /* Process 64K blocks region */
+   while (lptr_64k < rptr_64k) {
+   if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+   return SF_LOCKED;
+
+   bpr_ptr++;

Re: [U-Boot] [PATCH] x86: Use microcode update from device tree for all processors

[Bin Meng]

Hi Ivan,

On Thu, Apr 5, 2018 at 7:07 AM, Ivan Gorinov  wrote:
> The microcode update data block encoded in Device Tree is used by
> the bootstrap processor (BSP) but not passed to the other CPUs (AP).
>

I don't understand what the bug is here. The AP microcode update is
done in sipi_vector.S.

> If the bootstrap processor successfully performs a microcode update
> from Device Tree, use the same data block for the other processors.
>
> Signed-off-by: Ivan Gorinov 
> ---
>  arch/x86/cpu/i386/cpu.c   |  3 ++-
>  arch/x86/cpu/intel_common/car.S   |  2 ++
>  arch/x86/cpu/intel_common/microcode.c | 10 +++---
>  arch/x86/include/asm/microcode.h  |  1 +
>  arch/x86/lib/fsp/fsp_car.S|  2 ++
>  5 files changed, 14 insertions(+), 4 deletions(-)
>

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

Re: [U-Boot] [PATCHv2 1/6] reset: socfpga: add reset driver for SoCFPGA platform

[Marek Vasut]

On 04/05/2018 04:46 PM, Dinh Nguyen wrote:
> 
> 
> On 04/05/2018 09:12 AM, Dinh Nguyen wrote:
>> v
>>
>> On 04/04/2018 05:56 PM, Marek Vasut wrote:
>>> On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
 Add a DM compatible reset driver for the SoCFPGA platform.

 Signed-off-by: Dinh Nguyen 
>>>
>>> [...]
>>>
 +static int socfpga_reset_request(struct reset_ctl *reset_ctl)
 +{
 +  debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__,
 +reset_ctl, reset_ctl->dev, reset_ctl->id);
 +
 +  return 0;
 +}
 +
 +static int socfpga_reset_free(struct reset_ctl *reset_ctl)
 +{
 +  debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
 +reset_ctl->dev, reset_ctl->id);
 +
 +  return 0;
 +}
>>>
>>> Is request/free needed at all ? It looks like a useless debug to me.
>>>
>>
>> I used the code to debug that the i2c driver did hook into the reset
>> manager driver. Certainly, it can be removed in the final version. I'll
>> send a V3 shortly with this removed.
>>
> 
> I cannot remove the request function as this is needed in the
> reset-uclass driver.

Fix the driver please.

> Do you want me to remove free? Leaving the code
> there seems harmless to me.

Do a generic fix and then submit a fix for this driver, so two patches
in total. I'll apply the V2 for now.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv2 1/6] reset: socfpga: add reset driver for SoCFPGA platform

[Dinh Nguyen]

On Thu, Apr 5, 2018 at 11:28 AM, Marek Vasut  wrote:
> On 04/05/2018 04:46 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/05/2018 09:12 AM, Dinh Nguyen wrote:
>>> v
>>>
>>> On 04/04/2018 05:56 PM, Marek Vasut wrote:
 On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
> Add a DM compatible reset driver for the SoCFPGA platform.
>
> Signed-off-by: Dinh Nguyen 

 [...]

> +static int socfpga_reset_request(struct reset_ctl *reset_ctl)
> +{
> +  debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__,
> +reset_ctl, reset_ctl->dev, reset_ctl->id);
> +
> +  return 0;
> +}
> +
> +static int socfpga_reset_free(struct reset_ctl *reset_ctl)
> +{
> +  debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
> +reset_ctl->dev, reset_ctl->id);
> +
> +  return 0;
> +}

 Is request/free needed at all ? It looks like a useless debug to me.

>>>
>>> I used the code to debug that the i2c driver did hook into the reset
>>> manager driver. Certainly, it can be removed in the final version. I'll
>>> send a V3 shortly with this removed.
>>>
>>
>> I cannot remove the request function as this is needed in the
>> reset-uclass driver.
>
> Fix the driver please.
>
>> Do you want me to remove free? Leaving the code
>> there seems harmless to me.
>
> Do a generic fix and then submit a fix for this driver, so two patches
> in total. I'll apply the V2 for now.
>

Ok...will do.

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

[U-Boot] [PATCH] imx: mx7: snvs: Add an SNVS init routine

[Bryan O'Donoghue]

Working with HAB on the i.MX7 we've encountered a case where a board that
successfully authenticates u-boot when booting Linux via OPTEE subsequently
fails to properly bring up the RTC.

The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.

The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero. In ordinary
circumstances this is OK since we typically do not run in TZ mode, however
when we boot via HAB and enablng TrustZone, it is required to set
HPCOMR::NPSWA_EN = 1 in order for the upstream Linux driver to have
sufficient permissions to manipulate the SNVS-LP block.

On our reference board it is the difference between Linux doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x from SNVS_LPLR @ 0x0034
snvs_rtc_enable read 0x0021 from SNVS_LPCR @ 0x0038
snvs_rtc_enable read 0x from SNVS_HPLR @ 0x
snvs_rtc_enable read 0x80002100 from SNVS_HPCOMR @ 0x0004
snvs_rtc 3037.snvs:snvs-rtc-lp: rtc core: registered
 3037.snvs:snvs-rtc-lp as rtc0
snvs_rtc 3037.snvs:snvs-rtc-lp: setting system clock to2018-04-01 00:51:04 
UTC (1522543864)

and doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x from SNVS_LPLR @ 0x0034
snvs_rtc_enable read 0x0020 from SNVS_LPCR @ 0x0038
snvs_rtc_enable read 0x0001 from SNVS_HPLR @ 0x
snvs_rtc_enable read 0x2020 from SNVS_HPCOMR @ 0x0004
snvs_rtc 3037.snvs:snvs-rtc-lp: failed to enable rtc -110
snvs_rtc: probe of 3037.snvs:snvs-rtc-lp failed with error -110
hctosys: unable to open rtc device (rtc0)

Note bit 1 of LPCR is not set in the second case and is set in the first
case and that bit 31 of HPCOMR is set in the second case but not in the
first.

Setting NPSWA_EN in HPCOMR allows us to boot through enabling TrustZone
and continue onto the kernel. The kernel then has the necessary permissions
to set LPCR::SRTC_ENV (RTC enable in the LP command register) whereas in
contrast - in the failing case the non-privileged kernel cannot do so.

This patch adds a simple init_snvs() call which sets the permission-bit
called from soc.c for the i.MX7. It may be possible, safe and desirable to
perform this on other i.MX processors but for now this is only tested on
i.MX7 as working.

Signed-off-by: Bryan O'Donoghue 
---
 arch/arm/include/asm/mach-imx/sys_proto.h |  1 +
 arch/arm/mach-imx/mx7/Makefile|  2 +-
 arch/arm/mach-imx/mx7/snvs.c  | 22 ++
 arch/arm/mach-imx/mx7/soc.c   |  2 ++
 4 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-imx/mx7/snvs.c

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 96795e1..aa51c0d 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -107,6 +107,7 @@ void set_chipselect_size(int const);
 
 void init_aips(void);
 void init_src(void);
+void init_snvs(void);
 void imx_wdog_disable_powerdown(void);
 
 int board_mmc_get_env_dev(int devno);
diff --git a/arch/arm/mach-imx/mx7/Makefile b/arch/arm/mach-imx/mx7/Makefile
index ce289c1..e6bef6a 100644
--- a/arch/arm/mach-imx/mx7/Makefile
+++ b/arch/arm/mach-imx/mx7/Makefile
@@ -5,7 +5,7 @@
 #
 #
 
-obj-y  := soc.o clock.o clock_slice.o ddr.o
+obj-y  := soc.o clock.o clock_slice.o ddr.o snvs.o
 
 ifdef CONFIG_ARMV7_PSCI
 obj-y  += psci-mx7.o psci.o
diff --git a/arch/arm/mach-imx/mx7/snvs.c b/arch/arm/mach-imx/mx7/snvs.c
new file mode 100644
index 000..7e649b8
--- /dev/null
+++ b/arch/arm/mach-imx/mx7/snvs.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2018 Linaro
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+#define SNVS_HPCOMR0x04
+#define SNVS_HPCOMR_NPSWA_EN   BIT(31)
+
+void init_snvs(void)
+{
+   u32 val;
+
+   /* Ensure SNVS HPCOMR sets NPSWA_EN to allow unpriv access to SNVS LP */
+   val = readl(SNVS_BASE_ADDR + SNVS_HPCOMR);
+   val |= SNVS_HPCOMR_NPSWA_EN;
+   writel(val, SNVS_BASE_ADDR + SNVS_HPCOMR);
+}
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index fb92a26..3ceeeff 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -180,6 +180,8 @@ int arch_cpu_init(void)
isolate_resource();
 #endif
 
+   init_snvs();
+
return 0;
 }
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH] imx: mx7: snvs: Add an SNVS init routine

[Bryan O'Donoghue]

+ Stefano

On 05/04/18 19:46, Bryan O'Donoghue wrote:

Working with HAB on the i.MX7 we've encountered a case where a board that
successfully authenticates u-boot when booting Linux via OPTEE subsequently
fails to properly bring up the RTC.

The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.

The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero. In ordinary
circumstances this is OK since we typically do not run in TZ mode, however
when we boot via HAB and enablng TrustZone, it is required to set
HPCOMR::NPSWA_EN = 1 in order for the upstream Linux driver to have
sufficient permissions to manipulate the SNVS-LP block.

On our reference board it is the difference between Linux doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x from SNVS_LPLR @ 0x0034
snvs_rtc_enable read 0x0021 from SNVS_LPCR @ 0x0038
snvs_rtc_enable read 0x from SNVS_HPLR @ 0x
snvs_rtc_enable read 0x80002100 from SNVS_HPCOMR @ 0x0004
snvs_rtc 3037.snvs:snvs-rtc-lp: rtc core: registered
  3037.snvs:snvs-rtc-lp as rtc0
snvs_rtc 3037.snvs:snvs-rtc-lp: setting system clock to2018-04-01 00:51:04 
UTC (1522543864)

and doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x from SNVS_LPLR @ 0x0034
snvs_rtc_enable read 0x0020 from SNVS_LPCR @ 0x0038
snvs_rtc_enable read 0x0001 from SNVS_HPLR @ 0x
snvs_rtc_enable read 0x2020 from SNVS_HPCOMR @ 0x0004
snvs_rtc 3037.snvs:snvs-rtc-lp: failed to enable rtc -110
snvs_rtc: probe of 3037.snvs:snvs-rtc-lp failed with error -110
hctosys: unable to open rtc device (rtc0)

Note bit 1 of LPCR is not set in the second case and is set in the first
case and that bit 31 of HPCOMR is set in the second case but not in the
first.

Setting NPSWA_EN in HPCOMR allows us to boot through enabling TrustZone
and continue onto the kernel. The kernel then has the necessary permissions
to set LPCR::SRTC_ENV (RTC enable in the LP command register) whereas in
contrast - in the failing case the non-privileged kernel cannot do so.

This patch adds a simple init_snvs() call which sets the permission-bit
called from soc.c for the i.MX7. It may be possible, safe and desirable to
perform this on other i.MX processors but for now this is only tested on
i.MX7 as working.

Signed-off-by: Bryan O'Donoghue 
---
  arch/arm/include/asm/mach-imx/sys_proto.h |  1 +
  arch/arm/mach-imx/mx7/Makefile|  2 +-
  arch/arm/mach-imx/mx7/snvs.c  | 22 ++
  arch/arm/mach-imx/mx7/soc.c   |  2 ++
  4 files changed, 26 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/mach-imx/mx7/snvs.c

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 96795e1..aa51c0d 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -107,6 +107,7 @@ void set_chipselect_size(int const);
  
  void init_aips(void);

  void init_src(void);
+void init_snvs(void);
  void imx_wdog_disable_powerdown(void);
  
  int board_mmc_get_env_dev(int devno);

diff --git a/arch/arm/mach-imx/mx7/Makefile b/arch/arm/mach-imx/mx7/Makefile
index ce289c1..e6bef6a 100644
--- a/arch/arm/mach-imx/mx7/Makefile
+++ b/arch/arm/mach-imx/mx7/Makefile
@@ -5,7 +5,7 @@
  #
  #
  
-obj-y	:= soc.o clock.o clock_slice.o ddr.o

+obj-y  := soc.o clock.o clock_slice.o ddr.o snvs.o
  
  ifdef CONFIG_ARMV7_PSCI

  obj-y  += psci-mx7.o psci.o
diff --git a/arch/arm/mach-imx/mx7/snvs.c b/arch/arm/mach-imx/mx7/snvs.c
new file mode 100644
index 000..7e649b8
--- /dev/null
+++ b/arch/arm/mach-imx/mx7/snvs.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2018 Linaro
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+#define SNVS_HPCOMR0x04
+#define SNVS_HPCOMR_NPSWA_EN   BIT(31)
+
+void init_snvs(void)
+{
+   u32 val;
+
+   /* Ensure SNVS HPCOMR sets NPSWA_EN to allow unpriv access to SNVS LP */
+   val = readl(SNVS_BASE_ADDR + SNVS_HPCOMR);
+   val |= SNVS_HPCOMR_NPSWA_EN;
+   writel(val, SNVS_BASE_ADDR + SNVS_HPCOMR);
+}
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index fb92a26..3ceeeff 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -180,6 +180,8 @@ int arch_cpu_init(void)
isolate_resource();
  #endif
  
+	init_snvs();

+
return 0;
  }
  


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

Re: [U-Boot] [PATCH] imx: mx7: snvs: Add an SNVS init routine

[Fabio Estevam]

Hi Bryan,

On Thu, Apr 5, 2018 at 3:46 PM, Bryan O'Donoghue
 wrote:

> --- a/arch/arm/mach-imx/mx7/soc.c
> +++ b/arch/arm/mach-imx/mx7/soc.c
> @@ -180,6 +180,8 @@ int arch_cpu_init(void)
> isolate_resource();
>  #endif
>
> +   init_snvs();

Shouldn't this be called only if CONFIG_SECURE_BOOT is selected?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] efi_loader: Check machine type in the image header

[Ivan Gorinov]

Check FileHeader.Machine to make sure the EFI executable image is built
for the same architecture. For example, 32-bit U-Boot on x86 will print
an error message instead of loading an x86_64 image and crashing.

Signed-off-by: Ivan Gorinov 
---
 include/pe.h  | 24 
 lib/efi_loader/efi_image_loader.c | 24 
 2 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/include/pe.h b/include/pe.h
index c3a19ce..0dc33f0 100644
--- a/include/pe.h
+++ b/include/pe.h
@@ -38,11 +38,35 @@ typedef struct _IMAGE_DOS_HEADER {
 #define IMAGE_DOS_SIGNATURE0x5A4D /* MZ   */
 #define IMAGE_NT_SIGNATURE 0x4550 /* PE00 */
 
+#define IMAGE_FILE_MACHINE_I3860x014c
 #define IMAGE_FILE_MACHINE_ARM 0x01c0
 #define IMAGE_FILE_MACHINE_THUMB   0x01c2
 #define IMAGE_FILE_MACHINE_ARMNT   0x01c4
 #define IMAGE_FILE_MACHINE_AMD64   0x8664
 #define IMAGE_FILE_MACHINE_ARM64   0xaa64
+#define IMAGE_FILE_MACHINE_RISCV32 0x5032
+#define IMAGE_FILE_MACHINE_RISCV64 0x5064
+
+#if defined(CONFIG_ARM64)
+#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_ARM64
+#elif defined(CONFIG_ARM)
+#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_THUMB
+#endif
+
+#if defined(CONFIG_X86_64)
+#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_AMD64
+#elif defined(CONFIG_X86)
+#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_I386
+#endif
+
+#if defined(CONFIG_CPU_RISCV_32)
+#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_RISCV32
+#endif
+
+#if defined(CONFIG_CPU_RISCV_64)
+#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_RISCV64
+#endif
+
 #define IMAGE_NT_OPTIONAL_HDR32_MAGIC  0x10b
 #define IMAGE_NT_OPTIONAL_HDR64_MAGIC  0x20b
 #define IMAGE_SUBSYSTEM_EFI_APPLICATION10
diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index f588576..ac20488 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -172,14 +172,6 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
void *entry;
uint64_t image_size;
unsigned long virt_size = 0;
-   bool can_run_nt64 = true;
-   bool can_run_nt32 = true;
-
-#if defined(CONFIG_ARM64)
-   can_run_nt32 = false;
-#elif defined(CONFIG_ARM)
-   can_run_nt64 = false;
-#endif
 
dos = efi;
if (dos->e_magic != IMAGE_DOS_SIGNATURE) {
@@ -193,6 +185,16 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
return NULL;
}
 
+#ifdef TARGET_PE_MACHINE_TYPE
+
+   if (nt->FileHeader.Machine != TARGET_PE_MACHINE_TYPE) {
+   printf("%s: Machine type 0x%04x is not supported\n",
+  __func__, nt->FileHeader.Machine);
+   return NULL;
+   }
+
+#endif
+
/* Calculate upper virtual address boundary */
num_sections = nt->FileHeader.NumberOfSections;
sections = (void *)&nt->OptionalHeader +
@@ -205,8 +207,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
}
 
/* Read 32/64bit specific header bits */
-   if (can_run_nt64 &&
-   (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC)) {
+   if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
IMAGE_OPTIONAL_HEADER64 *opt = &nt64->OptionalHeader;
image_size = opt->SizeOfImage;
@@ -222,8 +223,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
virt_size = ALIGN(virt_size, opt->SectionAlignment);
-   } else if (can_run_nt32 &&
-  (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC)) 
{
+   } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
IMAGE_OPTIONAL_HEADER32 *opt = &nt->OptionalHeader;
image_size = opt->SizeOfImage;
efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2] efi_loader: Check machine type in the image header

[Alexander Graf]

On 05.04.18 23:28, Ivan Gorinov wrote:
> Check FileHeader.Machine to make sure the EFI executable image is built
> for the same architecture. For example, 32-bit U-Boot on x86 will print
> an error message instead of loading an x86_64 image and crashing.
> 
> Signed-off-by: Ivan Gorinov 
> ---
>  include/pe.h  | 24 
>  lib/efi_loader/efi_image_loader.c | 24 
>  2 files changed, 36 insertions(+), 12 deletions(-)
> 
> diff --git a/include/pe.h b/include/pe.h
> index c3a19ce..0dc33f0 100644
> --- a/include/pe.h
> +++ b/include/pe.h
> @@ -38,11 +38,35 @@ typedef struct _IMAGE_DOS_HEADER {
>  #define IMAGE_DOS_SIGNATURE  0x5A4D /* MZ   */
>  #define IMAGE_NT_SIGNATURE   0x4550 /* PE00 */
>  
> +#define IMAGE_FILE_MACHINE_I386  0x014c
>  #define IMAGE_FILE_MACHINE_ARM   0x01c0
>  #define IMAGE_FILE_MACHINE_THUMB 0x01c2
>  #define IMAGE_FILE_MACHINE_ARMNT 0x01c4
>  #define IMAGE_FILE_MACHINE_AMD64 0x8664
>  #define IMAGE_FILE_MACHINE_ARM64 0xaa64
> +#define IMAGE_FILE_MACHINE_RISCV32   0x5032
> +#define IMAGE_FILE_MACHINE_RISCV64   0x5064
> +
> +#if defined(CONFIG_ARM64)
> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_ARM64
> +#elif defined(CONFIG_ARM)
> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_THUMB

Are you sure we always have thumb as machine type here? Aren't we
compatible with either ARM or THUMB?

> +#endif
> +
> +#if defined(CONFIG_X86_64)
> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_AMD64
> +#elif defined(CONFIG_X86)
> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_I386
> +#endif
> +
> +#if defined(CONFIG_CPU_RISCV_32)
> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_RISCV32
> +#endif
> +
> +#if defined(CONFIG_CPU_RISCV_64)
> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_RISCV64
> +#endif
> +
>  #define IMAGE_NT_OPTIONAL_HDR32_MAGIC0x10b
>  #define IMAGE_NT_OPTIONAL_HDR64_MAGIC0x20b
>  #define IMAGE_SUBSYSTEM_EFI_APPLICATION  10
> diff --git a/lib/efi_loader/efi_image_loader.c 
> b/lib/efi_loader/efi_image_loader.c
> index f588576..ac20488 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -172,14 +172,6 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
> *loaded_image_info)
>   void *entry;
>   uint64_t image_size;
>   unsigned long virt_size = 0;
> - bool can_run_nt64 = true;
> - bool can_run_nt32 = true;
> -
> -#if defined(CONFIG_ARM64)
> - can_run_nt32 = false;
> -#elif defined(CONFIG_ARM)
> - can_run_nt64 = false;
> -#endif
>  
>   dos = efi;
>   if (dos->e_magic != IMAGE_DOS_SIGNATURE) {
> @@ -193,6 +185,16 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
> *loaded_image_info)
>   return NULL;
>   }
>  
> +#ifdef TARGET_PE_MACHINE_TYPE

I don't think we should have the #ifdef here. Let' make sure we always
know which platform we want to run on.


Alex

> +
> + if (nt->FileHeader.Machine != TARGET_PE_MACHINE_TYPE) {
> + printf("%s: Machine type 0x%04x is not supported\n",
> +__func__, nt->FileHeader.Machine);
> + return NULL;
> + }
> +
> +#endif
> +
>   /* Calculate upper virtual address boundary */
>   num_sections = nt->FileHeader.NumberOfSections;
>   sections = (void *)&nt->OptionalHeader +
> @@ -205,8 +207,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
> *loaded_image_info)
>   }
>  
>   /* Read 32/64bit specific header bits */
> - if (can_run_nt64 &&
> - (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC)) {
> + if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
>   IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
>   IMAGE_OPTIONAL_HEADER64 *opt = &nt64->OptionalHeader;
>   image_size = opt->SizeOfImage;
> @@ -222,8 +223,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
> *loaded_image_info)
>   rel_size = opt->DataDirectory[rel_idx].Size;
>   rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
>   virt_size = ALIGN(virt_size, opt->SectionAlignment);
> - } else if (can_run_nt32 &&
> -(nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC)) 
> {
> + } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
>   IMAGE_OPTIONAL_HEADER32 *opt = &nt->OptionalHeader;
>   image_size = opt->SizeOfImage;
>   efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] efi_loader: Check machine type in the image header

[Heinrich Schuchardt]

On 04/06/2018 12:43 AM, Alexander Graf wrote:
> 
> 
> On 05.04.18 23:28, Ivan Gorinov wrote:
>> Check FileHeader.Machine to make sure the EFI executable image is built
>> for the same architecture. For example, 32-bit U-Boot on x86 will print
>> an error message instead of loading an x86_64 image and crashing.
>>
>> Signed-off-by: Ivan Gorinov 
>> ---
>>  include/pe.h  | 24 
>>  lib/efi_loader/efi_image_loader.c | 24 
>>  2 files changed, 36 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/pe.h b/include/pe.h
>> index c3a19ce..0dc33f0 100644
>> --- a/include/pe.h
>> +++ b/include/pe.h
>> @@ -38,11 +38,35 @@ typedef struct _IMAGE_DOS_HEADER {
>>  #define IMAGE_DOS_SIGNATURE 0x5A4D /* MZ   */
>>  #define IMAGE_NT_SIGNATURE  0x4550 /* PE00 */
>>  
>> +#define IMAGE_FILE_MACHINE_I386 0x014c
>>  #define IMAGE_FILE_MACHINE_ARM  0x01c0
>>  #define IMAGE_FILE_MACHINE_THUMB0x01c2
>>  #define IMAGE_FILE_MACHINE_ARMNT0x01c4
>>  #define IMAGE_FILE_MACHINE_AMD640x8664
>>  #define IMAGE_FILE_MACHINE_ARM640xaa64
>> +#define IMAGE_FILE_MACHINE_RISCV32  0x5032
>> +#define IMAGE_FILE_MACHINE_RISCV64  0x5064
>> +
>> +#if defined(CONFIG_ARM64)
>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_ARM64
>> +#elif defined(CONFIG_ARM)
>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_THUMB
> 
> Are you sure we always have thumb as machine type here? Aren't we
> compatible with either ARM or THUMB?

The value 0x01c2 means ARM or THUMB
It is used by Linux, GRUB, iPXE.

Regards

Heinrich

> 
>> +#endif
>> +
>> +#if defined(CONFIG_X86_64)
>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_AMD64
>> +#elif defined(CONFIG_X86)
>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_I386
>> +#endif
>> +
>> +#if defined(CONFIG_CPU_RISCV_32)
>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_RISCV32
>> +#endif
>> +
>> +#if defined(CONFIG_CPU_RISCV_64)
>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_RISCV64
>> +#endif
>> +
>>  #define IMAGE_NT_OPTIONAL_HDR32_MAGIC   0x10b
>>  #define IMAGE_NT_OPTIONAL_HDR64_MAGIC   0x20b
>>  #define IMAGE_SUBSYSTEM_EFI_APPLICATION 10
>> diff --git a/lib/efi_loader/efi_image_loader.c 
>> b/lib/efi_loader/efi_image_loader.c
>> index f588576..ac20488 100644
>> --- a/lib/efi_loader/efi_image_loader.c
>> +++ b/lib/efi_loader/efi_image_loader.c
>> @@ -172,14 +172,6 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
>> *loaded_image_info)
>>  void *entry;
>>  uint64_t image_size;
>>  unsigned long virt_size = 0;
>> -bool can_run_nt64 = true;
>> -bool can_run_nt32 = true;
>> -
>> -#if defined(CONFIG_ARM64)
>> -can_run_nt32 = false;
>> -#elif defined(CONFIG_ARM)
>> -can_run_nt64 = false;
>> -#endif
>>  
>>  dos = efi;
>>  if (dos->e_magic != IMAGE_DOS_SIGNATURE) {
>> @@ -193,6 +185,16 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
>> *loaded_image_info)
>>  return NULL;
>>  }
>>  
>> +#ifdef TARGET_PE_MACHINE_TYPE
> 
> I don't think we should have the #ifdef here. Let' make sure we always
> know which platform we want to run on.
> 
> 
> Alex
> 
>> +
>> +if (nt->FileHeader.Machine != TARGET_PE_MACHINE_TYPE) {
>> +printf("%s: Machine type 0x%04x is not supported\n",
>> +   __func__, nt->FileHeader.Machine);
>> +return NULL;
>> +}
>> +
>> +#endif
>> +
>>  /* Calculate upper virtual address boundary */
>>  num_sections = nt->FileHeader.NumberOfSections;
>>  sections = (void *)&nt->OptionalHeader +
>> @@ -205,8 +207,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
>> *loaded_image_info)
>>  }
>>  
>>  /* Read 32/64bit specific header bits */
>> -if (can_run_nt64 &&
>> -(nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC)) {
>> +if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
>>  IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
>>  IMAGE_OPTIONAL_HEADER64 *opt = &nt64->OptionalHeader;
>>  image_size = opt->SizeOfImage;
>> @@ -222,8 +223,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
>> *loaded_image_info)
>>  rel_size = opt->DataDirectory[rel_idx].Size;
>>  rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
>>  virt_size = ALIGN(virt_size, opt->SectionAlignment);
>> -} else if (can_run_nt32 &&
>> -   (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC)) 
>> {
>> +} else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
>>  IMAGE_OPTIONAL_HEADER32 *opt = &nt->OptionalHeader;
>>  image_size = opt->SizeOfImage;
>>  efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
>>
> 

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

Re: [U-Boot] [PATCH v2] efi_loader: Check machine type in the image header

[Alexander Graf]

On 06.04.18 01:03, Heinrich Schuchardt wrote:
> On 04/06/2018 12:43 AM, Alexander Graf wrote:
>>
>>
>> On 05.04.18 23:28, Ivan Gorinov wrote:
>>> Check FileHeader.Machine to make sure the EFI executable image is built
>>> for the same architecture. For example, 32-bit U-Boot on x86 will print
>>> an error message instead of loading an x86_64 image and crashing.
>>>
>>> Signed-off-by: Ivan Gorinov 
>>> ---
>>>  include/pe.h  | 24 
>>>  lib/efi_loader/efi_image_loader.c | 24 
>>>  2 files changed, 36 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/include/pe.h b/include/pe.h
>>> index c3a19ce..0dc33f0 100644
>>> --- a/include/pe.h
>>> +++ b/include/pe.h
>>> @@ -38,11 +38,35 @@ typedef struct _IMAGE_DOS_HEADER {
>>>  #define IMAGE_DOS_SIGNATURE0x5A4D /* MZ   */
>>>  #define IMAGE_NT_SIGNATURE 0x4550 /* PE00 */
>>>  
>>> +#define IMAGE_FILE_MACHINE_I3860x014c
>>>  #define IMAGE_FILE_MACHINE_ARM 0x01c0
>>>  #define IMAGE_FILE_MACHINE_THUMB   0x01c2
>>>  #define IMAGE_FILE_MACHINE_ARMNT   0x01c4
>>>  #define IMAGE_FILE_MACHINE_AMD64   0x8664
>>>  #define IMAGE_FILE_MACHINE_ARM64   0xaa64
>>> +#define IMAGE_FILE_MACHINE_RISCV32 0x5032
>>> +#define IMAGE_FILE_MACHINE_RISCV64 0x5064
>>> +
>>> +#if defined(CONFIG_ARM64)
>>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_ARM64
>>> +#elif defined(CONFIG_ARM)
>>> +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_THUMB
>>
>> Are you sure we always have thumb as machine type here? Aren't we
>> compatible with either ARM or THUMB?
> 
> The value 0x01c2 means ARM or THUMB
> It is used by Linux, GRUB, iPXE.

I'm not sure that's fully accurate. ARM means some old legacy one, but
ARMNT and THUMB can both be used, no?

  https://www.npmjs.com/package/binarycpu

What I'm trying to say is that a 1:1 matching might not be the only
thing we want.


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

Re: [U-Boot] Pull request: u-boot-sunxi/master

[Tom Rini]

On Wed, Apr 04, 2018 at 02:25:09PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR, these changes were there since from last release.
> 
> thanks,
> Jagan.
> 
> The following changes since commit 0354f4bef0f1ff1e160673794577ca00b23f3f1a:
> 
>   sunxi: Add DRAM_SUN8I_A83T kconfig entry (2018-03-19 16:46:47 +0530)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to f3fed05e095439b3fd24990e20dbea1d4b03c121:
> 
>   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT" 
> (2018-04-04 14:15:40 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH v3] efi_loader: Check machine type in the image header

[Ivan Gorinov]

Check FileHeader.Machine to make sure the EFI executable image is built
for the same architecture. For example, 32-bit U-Boot on x86 will print
an error message instead of loading an x86_64 image and crashing.

Signed-off-by: Ivan Gorinov 
---
 include/pe.h  |  4 +++
 lib/efi_loader/efi_image_loader.c | 51 ++-
 2 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/include/pe.h b/include/pe.h
index c3a19ce..e7845bb 100644
--- a/include/pe.h
+++ b/include/pe.h
@@ -38,11 +38,15 @@ typedef struct _IMAGE_DOS_HEADER {
 #define IMAGE_DOS_SIGNATURE0x5A4D /* MZ   */
 #define IMAGE_NT_SIGNATURE 0x4550 /* PE00 */
 
+#define IMAGE_FILE_MACHINE_I3860x014c
 #define IMAGE_FILE_MACHINE_ARM 0x01c0
 #define IMAGE_FILE_MACHINE_THUMB   0x01c2
 #define IMAGE_FILE_MACHINE_ARMNT   0x01c4
 #define IMAGE_FILE_MACHINE_AMD64   0x8664
 #define IMAGE_FILE_MACHINE_ARM64   0xaa64
+#define IMAGE_FILE_MACHINE_RISCV32 0x5032
+#define IMAGE_FILE_MACHINE_RISCV64 0x5064
+
 #define IMAGE_NT_OPTIONAL_HDR32_MAGIC  0x10b
 #define IMAGE_NT_OPTIONAL_HDR64_MAGIC  0x20b
 #define IMAGE_SUBSYSTEM_EFI_APPLICATION10
diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index f588576..d5fbba3 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -22,6 +22,30 @@ const efi_guid_t efi_simple_file_system_protocol_guid =
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
 const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
 
+static int machines[] = {
+#if defined(CONFIG_ARM64)
+   IMAGE_FILE_MACHINE_ARM64,
+#elif defined(CONFIG_ARM)
+   IMAGE_FILE_MACHINE_ARM,
+   IMAGE_FILE_MACHINE_THUMB,
+   IMAGE_FILE_MACHINE_ARMNT,
+#endif
+
+#if defined(CONFIG_X86_64)
+   IMAGE_FILE_MACHINE_AMD64,
+#elif defined(CONFIG_X86)
+   IMAGE_FILE_MACHINE_I386,
+#endif
+
+#if defined(CONFIG_CPU_RISCV_32)
+   IMAGE_FILE_MACHINE_RISCV32,
+#endif
+
+#if defined(CONFIG_CPU_RISCV_64)
+   IMAGE_FILE_MACHINE_RISCV64,
+#endif
+   0 };
+
 /*
  * Print information about a loaded image.
  *
@@ -172,14 +196,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
void *entry;
uint64_t image_size;
unsigned long virt_size = 0;
-   bool can_run_nt64 = true;
-   bool can_run_nt32 = true;
-
-#if defined(CONFIG_ARM64)
-   can_run_nt32 = false;
-#elif defined(CONFIG_ARM)
-   can_run_nt64 = false;
-#endif
+   int supported = 0;
 
dos = efi;
if (dos->e_magic != IMAGE_DOS_SIGNATURE) {
@@ -193,6 +210,18 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
return NULL;
}
 
+   for (i = 0; machines[i]; i++)
+   if (machines[i] == nt->FileHeader.Machine) {
+   supported = 1;
+   break;
+   }
+
+   if (!supported) {
+   printf("%s: Machine type 0x%04x is not supported\n",
+  __func__, nt->FileHeader.Machine);
+   return NULL;
+   }
+
/* Calculate upper virtual address boundary */
num_sections = nt->FileHeader.NumberOfSections;
sections = (void *)&nt->OptionalHeader +
@@ -205,8 +234,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
}
 
/* Read 32/64bit specific header bits */
-   if (can_run_nt64 &&
-   (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC)) {
+   if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
IMAGE_OPTIONAL_HEADER64 *opt = &nt64->OptionalHeader;
image_size = opt->SizeOfImage;
@@ -222,8 +250,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
virt_size = ALIGN(virt_size, opt->SectionAlignment);
-   } else if (can_run_nt32 &&
-  (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC)) 
{
+   } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
IMAGE_OPTIONAL_HEADER32 *opt = &nt->OptionalHeader;
image_size = opt->SizeOfImage;
efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
-- 
2.7.4

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

[U-Boot] [RFC] efi_loader: support for CONFIG_ARMV7_NONSEC

[Heinrich Schuchardt]

Booting with SMP fails on the Allwinner A20 CPU.
https://gist.github.com/xypron/2524ba898d6905d959c744c2b05da196

When executing bootefi we need to
* copy the Power State Coordination Interface (PSCI) code to its
  destination address
* switch between our hypervisor mode (HYP) and the supervisor mode (SVC)
  of the payload (http://linux-sunxi.org/PSCI)

This patch is incomplete. It is just meant to indicate where we could
change the entry point.

With the patch iPXE cannot get a network address.

Possibly a better moment for switching to SVC is ExitBootServices.

We also have to consider switching modes at EFI_ENTRY and EFI_EXIT.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 85f7b42e76..af5adf8b29 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -17,8 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -176,8 +178,19 @@ static efi_status_t efi_do_enter(
 {
efi_status_t ret = EFI_LOAD_ERROR;
 
-   if (entry)
-   ret = entry(image_handle, st);
+   if (entry) {
+#ifdef CONFIG_ARMV7_NONSEC
+   if (armv7_boot_nonsec()) {
+   armv7_init_nonsec();
+   secure_ram_addr(_do_nonsec_entry)(entry,
+   (uintptr_t)image_handle,
+   (uintptr_t)st, 0);
+   } else
+#endif
+   {
+   ret = entry(image_handle, st);
+   }
+   }
st->boottime->exit(image_handle, ret, 0, NULL);
return ret;
 }
-- 
2.14.2

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

Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

[Maxime Ripard]

Hi Jaehoon,

On Wed, Mar 21, 2018 at 12:18:58PM +0100, Maxime Ripard wrote:
> From: Philipp Tomsich 
> 
> Throughput tests have shown the sunxi_mmc driver to take over 10s to
> read 10MB from a fast eMMC device due to excessive delays in polling
> loops.
> 
> This commit restructures the main polling loops to use get_timer(...)
> to determine whether a (millisecond) timeout has expired.  We choose
> not to use the wait_bit function, as we don't need interruptability
> with ctrl-c and have at least one case where two bits (one for an
> error condition and another one for completion) need to be read and
> using wait_bit would have not added to the clarity.
> 
> The observed speedup in testing on a A31 is greater than 10x (e.g. a
> 10MB write decreases from 9.302s to 0.884s).
> 
> Signed-off-by: Philipp Tomsich 
> Signed-off-by: Maxime Ripard 

Any chance we can merge this for the next release?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

[Jagan Teki]

On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard
 wrote:
> On Wed, Apr 04, 2018 at 12:13:01PM +0530, Jagan Teki wrote:
>> On Wed, Mar 21, 2018 at 4:48 PM, Maxime Ripard
>>  wrote:
>> > From: Philipp Tomsich 
>> >
>> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
>> > read 10MB from a fast eMMC device due to excessive delays in polling
>> > loops.
>> >
>> > This commit restructures the main polling loops to use get_timer(...)
>> > to determine whether a (millisecond) timeout has expired.  We choose
>> > not to use the wait_bit function, as we don't need interruptability
>> > with ctrl-c and have at least one case where two bits (one for an
>> > error condition and another one for completion) need to be read and
>> > using wait_bit would have not added to the clarity.
>> >
>> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
>> > 10MB write decreases from 9.302s to 0.884s).
>>
>> Fyi: I've seen significant improvement, but not 10x on A64
>> (bananpi-m64) with read
>>
>> Before this change:
>>
>> => mmc dev 0
>> switch to partitions #0, OK
>> mmc0 is current device
>> => fatload mmc 0:1 $kernel_addr_r Image
>> reading Image
>> 16310784 bytes read in 821 ms (18.9 MiB/s)
>> => mmc dev 1
>> switch to partitions #0, OK
>> mmc1(part 0) is current device
>> => ext4load mmc 1:1 $kernel_addr_r Image
>> 16310784 bytes read in 1109 ms (14 MiB/s)
>>
>>
>> After this change:
>>
>> => mmc dev 0
>> switch to partitions #0, OK
>> mmc0 is current device
>> => fatload mmc 0:1 $kernel_addr_r Image
>> 16310784 bytes read in 784 ms (19.8 MiB/s)
>> => mmc dev 1
>> switch to partitions #0, OK
>> mmc1(part 0) is current device
>> => ext4load mmc 1:1 $kernel_addr_r Image
>> 16310784 bytes read in 793 ms (19.6 MiB/s)
>
> Yeah, the smaller the file is, the bigger the gain is. Since you have
> an almost twice bigger file, the gains are probably just noise at that
> point and the bottleneck starts to be your MMC.

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

Re: [U-Boot] [PATCH v2] efi_loader: Check machine type in the image header

[Heinrich Schuchardt]

On 04/06/2018 01:23 AM, Alexander Graf wrote:
> 
> 
> On 06.04.18 01:03, Heinrich Schuchardt wrote:
>> On 04/06/2018 12:43 AM, Alexander Graf wrote:
>>>
>>>
>>> On 05.04.18 23:28, Ivan Gorinov wrote:
 Check FileHeader.Machine to make sure the EFI executable image is built
 for the same architecture. For example, 32-bit U-Boot on x86 will print
 an error message instead of loading an x86_64 image and crashing.

 Signed-off-by: Ivan Gorinov 
 ---
  include/pe.h  | 24 
  lib/efi_loader/efi_image_loader.c | 24 
  2 files changed, 36 insertions(+), 12 deletions(-)

 diff --git a/include/pe.h b/include/pe.h
 index c3a19ce..0dc33f0 100644
 --- a/include/pe.h
 +++ b/include/pe.h
 @@ -38,11 +38,35 @@ typedef struct _IMAGE_DOS_HEADER {
  #define IMAGE_DOS_SIGNATURE   0x5A4D /* MZ   */
  #define IMAGE_NT_SIGNATURE0x4550 /* PE00 */
  
 +#define IMAGE_FILE_MACHINE_I386   0x014c
  #define IMAGE_FILE_MACHINE_ARM0x01c0
  #define IMAGE_FILE_MACHINE_THUMB  0x01c2
  #define IMAGE_FILE_MACHINE_ARMNT  0x01c4
  #define IMAGE_FILE_MACHINE_AMD64  0x8664
  #define IMAGE_FILE_MACHINE_ARM64  0xaa64
 +#define IMAGE_FILE_MACHINE_RISCV320x5032
 +#define IMAGE_FILE_MACHINE_RISCV640x5064
 +
 +#if defined(CONFIG_ARM64)
 +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_ARM64
 +#elif defined(CONFIG_ARM)
 +#define TARGET_PE_MACHINE_TYPE IMAGE_FILE_MACHINE_THUMB
>>>
>>> Are you sure we always have thumb as machine type here? Aren't we
>>> compatible with either ARM or THUMB?
>>
>> The value 0x01c2 means ARM or THUMB
>> It is used by Linux, GRUB, iPXE.
> 
> I'm not sure that's fully accurate. ARM means some old legacy one, but
> ARMNT and THUMB can both be used, no?
> 
>   https://www.npmjs.com/package/binarycpu
> 
> What I'm trying to say is that a 1:1 matching might not be the only
> thing we want.

Revision 8.3 – February 6th, 2013 of the PECOFF spec is the most explicit:

IMAGE_FILE_MACHINE_ARMNT 0x1c4 ARMv7 (or higher) Thumb mode only
IMAGE_FILE_MACHINE_THUMB 0x1c2 ARM or Thumb (“interworking”)

EDK2 has only these values (with some names not matching the standard):

IMAGE_FILE_MACHINE_I3860x014c
IMAGE_FILE_MACHINE_IA640x0200
IMAGE_FILE_MACHINE_EBC 0x0EBC
IMAGE_FILE_MACHINE_X64 0x8664
IMAGE_FILE_MACHINE_ARMTHUMB_MIXED  0x01c2
IMAGE_FILE_MACHINE_ARM64   0xAA64

On ARM only IMAGE_FILE_MACHINE_ARMTHUMB_MIXED and
IMAGE_FILE_MACHINE_ARMTHUMB_MIXED are IMAGE_FILE_MACHINE_EBC are
supported. But we do not support IMAGE_FILE_MACHINE_EBC.

So EDK2 would not be able load a 0x01c4 ARM binary.

Best regards

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

[U-Boot] Question regarding cpu_get_count(..)

[Christian Gmeiner]

Hi

I tried my luck on the u-boot irc channel but nobody cared so I am
asking this here again.
Does cpu_get_count(..) return the number of physical CPUs or the
number of logical CPUs?

I am currently preparing a patch set which adds
arch/x86/cpu/queensbay/cpu.c and there I need
to specify a struct cpu_ops with a function called get_count(). But
what must I return (physical vs. logical CPU count)?

-- 
thanks
--
Christian Gmeiner, MSc

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