[PATCH] ARM: MediaTek: amend IC description for MediaTek MT8512

2020-09-03 Thread mingming lee
From: Mingming Lee 

The description for MT8512  has some mistake, so correct it.

Signed-off-by: Mingming Lee 
---
 arch/arm/mach-mediatek/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
index 0042e57017..7f40ba9319 100644
--- a/arch/arm/mach-mediatek/Kconfig
+++ b/arch/arm/mach-mediatek/Kconfig
@@ -47,10 +47,10 @@ config TARGET_MT8512
 select ARM64
select MT8512
 help
-  The MediaTek MT8512 is a ARM64-based SoC with a quad-core Cortex-A53.
+  The MediaTek MT8512 is a ARM64-based SoC with a dual-core Cortex-A53.
   including UART, SPI, USB2.0 and OTG, SD and MMC cards, NAND, PWM,
-  Ethernet, IR TX/RX, I2C, I2S, S/PDIF, and built-in Wi-Fi / Bluetooth 
combo
-  chip and several DDR3 and DDR4 options.
+  IR RX, I2C, I2S, S/PDIF, and built-in Wi-Fi / Bluetooth digital
+  and several LPDDR3 and LPDDR4 options.
 
 config TARGET_MT8516
bool "MediaTek MT8516 SoC"
-- 
2.18.0


Re: [PATCH] spl: Avoid printing boot device if silent console is enabled

2020-09-03 Thread Stefan Roese

On 03.09.20 19:25, Otavio Salvador wrote:

Signed-off-by: Otavio Salvador 
---

  common/spl/spl.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 4840d1d367..63c48fbf33 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -552,7 +552,9 @@ static int boot_from_devices(struct spl_image_info 
*spl_image,
struct spl_image_loader *loader;
  
  		loader = spl_ll_find_loader(spl_boot_list[i]);

-#if defined(CONFIG_SPL_SERIAL_SUPPORT) && defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if defined(CONFIG_SPL_SERIAL_SUPPORT) \
+&& defined(CONFIG_SPL_LIBCOMMON_SUPPORT)\
+&& !defined(CONFIG_SILENT_CONSOLE)


Nitpicking:
I think its preferred to put the "&&" (or "||") at the end of the line.

Other than that:

Reviewed-by: Stefan Roese 

Thanks,
Stefan


Re: RPi4 U-Boot freeze

2020-09-03 Thread Bin Meng
On Thu, Sep 3, 2020 at 7:23 PM Stefan Agner  wrote:
>
> Any thoughts on this issue?
>
> Just to be sure, I did some memory testing on the 2GB module, but no
> issues found.
>
> I still somehow suspected that something else might be wrong with my
> hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the
> very same with that:
>
> U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +)
>
> DRAM:  3.9 GiB
> 
>
> I still think there is something wrong with caching. From what I
> understand caches are enabled by the RPi (4) firmware. Is it safe to run
> 32-bit ARM U-Boot with enabled caches?
>
> --
> Stefan
>
> On 2020-08-23 19:06, Stefan Agner wrote:
> > Hi,
> >
> > I noticed a quite common freeze when running 32-bit U-Boot 2020.01
> > (rpi_4_32b_defconfig) on a 2GB RPi4 model:
> >
> > U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +)
> >
> > DRAM:  1.9 GiB
> > 
> >
> > This happens fairly often, I would say 4 out of 5 boot tries. However,
> > if it boots, everything seems to run fine.
> >
> > The issue seems to go away when using 2020.04 or any newer release,
> > however, when trying to find the actual patch fixing the issue using git
> > bisect I ended up with a MMC merge request which really seems unrelated
> > (36bdcf7f3b). It seems that the problem is quite evasive and disappears
> > if certain structure are aligned differently etc.
> >
> > Enabling initcall debugging showed that U-Boot crashes right after
> > relocation:

I suspect there are some timing issues in the DDR training codes.

Regards,
Bin


[PATCH 1/5] x86: Use multiple images

2020-09-03 Thread Simon Glass
We already use binman's 'multiple-images' feature with Chrome OS and we
want to use it for Edison. There is no real down-side.

Adjust x86 to always use multiple-images.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/u-boot.dtsi | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index fa8106c8b8c..90badcc15c9 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -6,7 +6,6 @@
 
 #include 
 
-#ifdef CONFIG_CHROMEOS
 / {
binman {
multiple-images;
@@ -14,12 +13,6 @@
};
};
 };
-#else
-/ {
-   rom: binman {
-   };
-};
-#endif
 
 #ifdef CONFIG_ROM_SIZE
  {
-- 
2.28.0.526.ge36021eeef-goog



[PATCH 3/5] binman: Support adding a U-Boot environment

2020-09-03 Thread Simon Glass
In some cases it is useful to include a U-Boot environment region in an
image. This allows the board to start up with an environment ready to go.

Add a new entry type for this. The input is a text file containing the
environment entries, one per line, in the format:

   var=value

Signed-off-by: Simon Glass 
---

 tools/binman/etype/u_boot_env.py| 42 +
 tools/binman/ftest.py   | 31 ++
 tools/binman/test/174_env.dts   | 20 
 tools/binman/test/175_env_no_size.dts   | 19 +++
 tools/binman/test/176_env_too_small.dts | 20 
 5 files changed, 132 insertions(+)
 create mode 100644 tools/binman/etype/u_boot_env.py
 create mode 100644 tools/binman/test/174_env.dts
 create mode 100644 tools/binman/test/175_env_no_size.dts
 create mode 100644 tools/binman/test/176_env_too_small.dts

diff --git a/tools/binman/etype/u_boot_env.py b/tools/binman/etype/u_boot_env.py
new file mode 100644
index 000..1694c2a6eef
--- /dev/null
+++ b/tools/binman/etype/u_boot_env.py
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2018 Google, Inc
+# Written by Simon Glass 
+#
+
+import struct
+import zlib
+
+from binman.etype.blob import Entry_blob
+from dtoc import fdt_util
+from patman import tools
+
+class Entry_u_boot_env(Entry_blob):
+"""An entry which contains a U-Boot environment
+
+Properties / Entry arguments:
+- filename: File containing the environment text, with each line in the
+form var=value
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node)
+
+def ReadNode(self):
+super().ReadNode()
+if self.size is None:
+self.Raise("'u-boot-env' entry must have a size property")
+self.fill_value = fdt_util.GetByte(self._node, 'fill-byte', 0)
+
+def ReadBlobContents(self):
+indata = tools.ReadFile(self._pathname)
+data = b''
+for line in indata.splitlines():
+data += line + b'\0'
+data += b'\0';
+pad = self.size - len(data) - 5
+if pad < 0:
+self.Raise("'u-boot-env' entry too small to hold data (need %#x 
more bytes)" % -pad)
+data += tools.GetBytes(self.fill_value, pad)
+crc = zlib.crc32(data)
+buf = struct.pack(';
+   #size-cells = <1>;
+
+   binman {
+   u-boot {
+   };
+   u-boot-env {
+   filename = "env.txt";
+   size = <0x18>;
+   fill-byte = [ff];
+   };
+   u-boot-nodtb {
+   };
+   };
+};
diff --git a/tools/binman/test/175_env_no_size.dts 
b/tools/binman/test/175_env_no_size.dts
new file mode 100644
index 000..267acd15491
--- /dev/null
+++ b/tools/binman/test/175_env_no_size.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   u-boot {
+   };
+   u-boot-env {
+   filename = "env.txt";
+   fill-byte = [ff];
+   };
+   u-boot-nodtb {
+   };
+   };
+};
diff --git a/tools/binman/test/176_env_too_small.dts 
b/tools/binman/test/176_env_too_small.dts
new file mode 100644
index 000..2db8d054639
--- /dev/null
+++ b/tools/binman/test/176_env_too_small.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   u-boot {
+   };
+   u-boot-env {
+   filename = "env.txt";
+   size = <0x8>;
+   fill-byte = [ff];
+   };
+   u-boot-nodtb {
+   };
+   };
+};
-- 
2.28.0.526.ge36021eeef-goog



[PATCH 5/5] x86: edison: Add documentation for using am xFSTK image

2020-09-03 Thread Simon Glass
Add a description of how to flash Edison using the XFSTK tool.

Signed-off-by: Simon Glass 
---

 doc/board/intel/edison.rst | 120 +
 1 file changed, 120 insertions(+)

diff --git a/doc/board/intel/edison.rst b/doc/board/intel/edison.rst
index 1aee2a1fc0d..40acd80a051 100644
--- a/doc/board/intel/edison.rst
+++ b/doc/board/intel/edison.rst
@@ -39,3 +39,123 @@ use.
reset the board::
 
=> reset
+
+
+Updating U-Boot using xFSTK
+---
+
+You can also update U-Boot using the xfstk-dldr-solo tool if you can build it.
+One way to do that is to follow the `xFSTK`_ instructions. You may need to use
+a virtual machine running Ubuntu Trusty. Once you have built it and installed
+libboost-all-dev, you can copy xfstk-dldr-solo to /usr/local/bin and
+libboost_program_options.so.1.54.0 to /usr/lib/i386-linux-gnu/ and with luck
+it will work. You might fine this `drive`_ helpful.
+
+If it does, then you can download and unpack the Edison reocovery image,
+install dfu-util, reset your board and flash U-Boot like this::
+
+   $ xfstk-dldr-solo --gpflags 0x8007 \
+  --osimage u-boot-edison.img \
+  --fwdnx recover/edison_dnx_fwr.bin \
+  --fwimage recover/edison_ifwi-dbg-00.bin \
+  --osdnx recover/edison_dnx_osr.bin
+
+This should show the following
+
+.. code-block:: none
+
+  XFSTK Downloader Solo 0.0.0
+  Copyright (c) 2015 Intel Corporation
+  Build date and time: Aug 15 2020 15:07:13
+
+  .Intel SoC Device Detection Found
+  Parsing Commandline
+  Registering Status Callback
+  .Initiating Download Process
+  ...(lots of dots)XFSTK-STATUS--Reconnecting to device - Attempt 
#1
+  ...(even more dots)..
+
+
+You have about 10 seconds after resetting the board to type the above command.
+If you want to check if the board is ready, type:
+
+.. code-block:: none
+
+  lsusb |egrep "8087|8086"
+  Bus 001 Device 004: ID 8086:e005 Intel Corp.
+
+If you see a device with the same ID as above, the board is waiting for your
+command.
+
+After about 5 seconds you should see some console output from the board:
+
+.. code-block:: none
+
+  **
+  PSH KERNEL VERSION: b0182b2b
+   WR: 20104000
+  **
+
+  SCU IPC: 0x80d0  0xfffce92c
+
+  PSH miaHOB version: TNG.B0.VVBD.000c
+
+  microkernel built 11:24:08 Feb  5 2015
+
+  *** PSH loader ***
+  PCM page cache size = 192 KB
+  Cache Constraint = 0 Pages
+  Arming IPC driver ..
+  Adding page store pool ..
+  PagestoreAddr(IMR Start Address) = 0x04899000
+  pageStoreSize(IMR Size)  = 0x0008
+
+  *** Ready to receive application ***
+
+  After another 10 seconds the xFSTK tool completes and the board resets. About
+  10 seconds after that should see the above message again and then within a
+  few seconds U-Boot should start on your board:
+
+.. code-block:: none
+
+  U-Boot 2020.10-rc3-00032-gd9f6680e925-dirty (Sep 03 2020 - 18:44:28 -0600)
+
+  CPU:   Genuine Intel(R) CPU   4000  @  500MHz
+  DRAM:  980.6 MiB
+  WDT:   Started with servicing (60s timeout)
+  MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
+  Loading Environment from MMC... OK
+  In:serial
+  Out:   serial
+  Err:   serial
+  Saving Environment to MMC... Writing to redundant MMC(0)... OK
+  Saving Environment to MMC... Writing to MMC(0)... OK
+  Net:   No ethernet found.
+  Hit any key to stop autoboot:  0
+  Target:blank
+  Partitioning using GPT
+  Writing GPT: success!
+  Saving Environment to MMC... Writing to redundant MMC(0)... OK
+  Flashing already done...
+  5442816 bytes read in 238 ms (21.8 MiB/s)
+  Valid Boot Flag
+  Setup Size = 0x3c00
+  Magic signature found
+  Using boot protocol version 2.0c
+  Linux kernel version 3.10.17-poky-edison+ (ferry@kalamata) #1 SMP PREEMPT 
Mon Jan 11 14:54:18 CET 2016
+  Building boot_params at 0x0009
+  Loading bzImage at address 10 (5427456 bytes)
+  Magic signature found
+  Kernel command line: "rootwait 
root=PARTUUID=ada722ed-6410-764e-8619-abff6f66e10e rootfstype=ext4 
console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc 
systemd.unit=multi-user.target hardware_id=00 
g_multi.iSerialNumber=2249baf774c675598661a63098c0ad41 
g_multi.dev_addr=02:00:86:c0:ad:41 platform_mrfld_audio.audio_codec=dummy"
+  Magic signature found
+
+  Starting kernel ...
+
+  ...
+
+  Poky (Yocto Project Reference Distro) 1.7.2 edison ttyMFD2
+
+  edison login:
+
+.. _xFSTK: 
https://community.intel.com/t5/Intel-Makers/Building-xFSTK-on-Ubuntu-14-04-32-bit-for-flashing-Edison/td-p/538081
+.. _drive: 
https://drive.google.com/drive/u/0/folders/1URPHrOk9-UBsh8hjv-7WwC0W6Fy61uAJ
-- 
2.28.0.526.ge36021eeef-goog



[PATCH 4/5] x86: edison: Generate an image suitable for xFSTK

2020-09-03 Thread Simon Glass
It is useful to be able to flash Edison directly without relying on the
installed U-Boot being functional.

Add a binman image for this. It includes a master-boot record, U-Boot
binary and an environment.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/tangier/Kconfig  |   1 +
 arch/x86/dts/edison.dts   |  34 +++
 board/intel/edison/edison-environment.txt |  48 ++
 board/intel/edison/edison-mbr.dat | Bin 0 -> 512 bytes
 4 files changed, 83 insertions(+)
 create mode 100644 board/intel/edison/edison-environment.txt
 create mode 100644 board/intel/edison/edison-mbr.dat

diff --git a/arch/x86/cpu/tangier/Kconfig b/arch/x86/cpu/tangier/Kconfig
index d2b7edecd60..571470c74b2 100644
--- a/arch/x86/cpu/tangier/Kconfig
+++ b/arch/x86/cpu/tangier/Kconfig
@@ -12,6 +12,7 @@ config INTEL_TANGIER
imply MMC_SDHCI_TANGIER
imply USB
imply USB_DWC3
+   imply BINMAN
 
 if INTEL_TANGIER
 
diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index df24aa0d26a..b5aac6b7349 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -22,6 +22,10 @@
serial2 = 
};
 
+   binman: binman {
+   multiple-images;
+   };
+
chosen {
stdout-path = 
};
@@ -130,3 +134,33 @@
};
};
 };
+
+ {
+   u-boot-edison {
+   filename = "u-boot-edison.img";
+
+   /* This is Master-Boot Record */
+   blob {
+   filename = "edison-mbr.dat";
+   };
+
+   u-boot {
+   offset = <0x200>;
+   };
+
+   u-boot-env {
+   offset = <0x200200>;
+   filename = "edison-environment.txt";
+   size = <0x1>;
+   fill-byte = [ff];
+   };
+
+   u-boot-env2 {
+   type = "u-boot-env";
+   offset = <0x500200>;
+   filename = "edison-environment.txt";
+   size = <0x1>;
+   fill-byte = [ff];
+   };
+   };
+};
diff --git a/board/intel/edison/edison-environment.txt 
b/board/intel/edison/edison-environment.txt
new file mode 100644
index 000..afe00920461
--- /dev/null
+++ b/board/intel/edison/edison-environment.txt
@@ -0,0 +1,48 @@
+partitions=uuid_disk=${uuid_disk};name=u-boot0,start=1MiB,size=2MiB,uuid=${uuid_uboot0};name=u-boot-env0,size=1MiB,uuid=${uuid_uboot_env0};name=u-boot1,size=2MiB,uuid=${uuid_uboot1};name=u-boot-env1,size=1MiB,uuid=${uuid_uboot_env1};name=factory,size=1MiB,uuid=${uuid_factory};name=panic,size=24MiB,uuid=${uuid_panic};name=boot,size=32MiB,uuid=${uuid_boot};name=rootfs,size=1536MiB,uuid=${uuid_rootfs};name=update,size=768MiB,uuid=${uuid_update};name=home,size=-,uuid=${uuid_home};
+do_dfu_alt_info_mmc=setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart 
1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0 part 0 1;u-boot-env0 part 0 
2;u-boot1 part 0 3;u-boot-env1 part 0 4;boot part 0 7;rootfs part 0 8;update 
part 0 9;home part 0 10;vmlinuz fat 0 7;initrd fat 0 7"
+dfu_alt_info_ram=kernel ram ${loadaddr} 0x80
+do_dfu_alt_info_ifwi=setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 
mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2"
+dfu_alt_info_reset=reset ram 0x0 0x0
+bootargs_console=console=ttyMFD2 earlyprintk=ttyMFD2,keep
+bootargs_debug=loglevel=4
+do_bootargs_rootfs=setenv bootargs_rootfs rootwait 
root=PARTUUID=${uuid_rootfs} rootfstype=ext4
+first_install_retry=0
+first_install_max_retries=3
+ota_update_retry=0
+ota_update_max_retries=3
+audio_codec_name=audio_codec="dummy"
+do_audio_support=setenv audio_support platform_mrfld_audio.${audio_codec_name}
+do_compute_target=if itest.b ${first_install_retry} -gt 
${first_install_max_retries} || itest.b ${ota_update_retry} -gt 
${ota_update_max_retries}; then echo "Switch to Rescue target"; setenv 
bootargs_target rescue; saveenv; fi
+mmc-bootargs=run do_bootargs_rootfs; run do_audio_support; setenv bootargs 
${bootargs_rootfs} ${bootargs_console} ${bootargs_debug} 
g_multi.ethernet_config=${bootargs_ethconfig} 
systemd.unit=${bootargs_target}.target hardware_id=${hardware_id} 
g_multi.iSerialNumber=${serial#} g_multi.dev_addr=${usb0addr} ${audio_support}
+loadaddr=0x10
+load_kernel=fatload mmc 0:7 ${loadaddr} vmlinuz
+do_partition_done=0
+do_partition=if itest.b ${do_partition_done} -eq 1; then echo "Partitioning 
already done..."; else run do_force_partition ; fi
+do_force_partition=echo "Partitioning using GPT"; gpt write mmc 0 
${partitions} ; mmc rescan; setenv do_partition_done 1 ; saveenv
+do_flash_ifwi=run do_dfu_alt_info_ifwi ; dfu 0 mmc 0 $dfu_to_sec
+do_flash_os=if itest.b ${do_flash_os_done} -eq 1 ; then echo "Flashing already 
done..." ; else run do_force_flash_os; fi
+do_force_flash_os=run 

[PATCH 2/5] binman: Show an error when a file is missing

2020-09-03 Thread Simon Glass
The recent support for missing external binaries does not show an error
message when a file is genuinely missing (i.e. it is missing but not
marked as 'external'). This means that when -m is passed to binman, it
will never report a missing file.

Fix this and add a test.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/blob.py |  7 ---
 tools/binman/ftest.py  |  7 +++
 tools/binman/test/173_missing_blob.dts | 14 ++
 3 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 tools/binman/test/173_missing_blob.dts

diff --git a/tools/binman/etype/blob.py b/tools/binman/etype/blob.py
index c5f97c85a38..66cf243976e 100644
--- a/tools/binman/etype/blob.py
+++ b/tools/binman/etype/blob.py
@@ -37,13 +37,14 @@ class Entry_blob(Entry):
 
 def ObtainContents(self):
 self._filename = self.GetDefaultFilename()
-self._pathname = tools.GetInputFilename(self._filename,
-self.section.GetAllowMissing())
+self._pathname = tools.GetInputFilename(
+self._filename, self.external and self.section.GetAllowMissing())
 # Allow the file to be missing
-if self.external and not self._pathname:
+if not self._pathname:
 self.SetContents(b'')
 self.missing = True
 return True
+
 self.ReadBlobContents()
 return True
 
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 95b17d0b749..91225459162 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -3708,5 +3708,12 @@ class TestFunctional(unittest.TestCase):
 self.assertIn('Wibble test', err)
 self.assertIn('Another test', err)
 
+def testMissingBlob(self):
+"""Test handling of a blob containing a missing file"""
+with self.assertRaises(ValueError) as e:
+self._DoTestFile('173_missing_blob.dts', allow_missing=True)
+self.assertIn("Filename 'missing' not found in input path",
+  str(e.exception))
+
 if __name__ == "__main__":
 unittest.main()
diff --git a/tools/binman/test/173_missing_blob.dts 
b/tools/binman/test/173_missing_blob.dts
new file mode 100644
index 000..ffb655a1cb4
--- /dev/null
+++ b/tools/binman/test/173_missing_blob.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   blob {
+   filename = "missing";
+   };
+   };
+};
-- 
2.28.0.526.ge36021eeef-goog



[PATCH 0/5] edison: Support for writing an xFSTK image

2020-09-03 Thread Simon Glass
At present it is painful to put Edison in a hardware lab because it has
two separate recovery modes. When the board has a functioning U-Boot, DFU
can be used. Otherwise an xFSTK image must be used.

This series converts Andy's script to a binman description so that U-Boot
can produce an xFSTK image directly.

With this, I can put an Edison in my lab fairly easily.

The series is available at u-boot-dm/edison-working and is based on the
reset binman series for sunxi.

[1] https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f


Simon Glass (5):
  x86: Use multiple images
  binman: Show an error when a file is missing
  binman: Support adding a U-Boot environment
  x86: edison: Generate an image suitable for xFSTK
  x86: edison: Add documentation for using am xFSTK image

 arch/x86/cpu/tangier/Kconfig  |   1 +
 arch/x86/dts/edison.dts   |  34 ++
 arch/x86/dts/u-boot.dtsi  |   7 --
 board/intel/edison/edison-environment.txt |  48 +
 board/intel/edison/edison-mbr.dat | Bin 0 -> 512 bytes
 doc/board/intel/edison.rst| 120 ++
 tools/binman/etype/blob.py|   7 +-
 tools/binman/etype/u_boot_env.py  |  42 
 tools/binman/ftest.py |  38 +++
 tools/binman/test/173_missing_blob.dts|  14 +++
 tools/binman/test/174_env.dts |  20 
 tools/binman/test/175_env_no_size.dts |  19 
 tools/binman/test/176_env_too_small.dts   |  20 
 13 files changed, 360 insertions(+), 10 deletions(-)
 create mode 100644 board/intel/edison/edison-environment.txt
 create mode 100644 board/intel/edison/edison-mbr.dat
 create mode 100644 tools/binman/etype/u_boot_env.py
 create mode 100644 tools/binman/test/173_missing_blob.dts
 create mode 100644 tools/binman/test/174_env.dts
 create mode 100644 tools/binman/test/175_env_no_size.dts
 create mode 100644 tools/binman/test/176_env_too_small.dts

-- 
2.28.0.526.ge36021eeef-goog



Re: [RESEND PATCH v2 01/11] usb: xhci: add a member hci_version in xhci_ctrl struct

2020-09-03 Thread Bin Meng
On Wed, Sep 2, 2020 at 2:14 PM Frank Wunderlich  wrote:
>
> From: Chunfeng Yun 
>
> Add a member to save xHCI version, it's used some times.
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/usb/host/xhci-ring.c | 4 ++--
>  drivers/usb/host/xhci.c  | 1 +
>  include/usb/xhci.h   | 1 +
>  3 files changed, 4 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


flash-kernel: Add vendor path for some arm64 machines

2020-09-03 Thread Vagrant Cascadian
Package: flash-kernel
Tags: patch
Control: submitter -1 a.hei...@gmail.com
X-Debbugs-Cc: Andre Heider 

I'm submitting this to the Debian bug tracking system, since this isn't
directly related to u-boot. I've dropped most of the CCs on the thread,
presumably should also drop the u-boot CC on follow-ups.


On 2020-09-03, Andre Heider wrote:
> On 03/09/2020 20:59, Vagrant Cascadian wrote:
>> On 2020-09-03, Andre Heider wrote:
>>> On 03/09/2020 18:40, Dennis Gilmore wrote:
>>> If so, adding fdtfile like that would break booting debian using its
>>> flash-image. It installs dtbs without that subdir into /boot:
>>> /boot/dtbs/4.19.0-9-arm64/armada-3720-espressobin.dtb
>>>
>>> But it already supports $fdtfile:
>>> https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/arm64/bootscr.uboot-generic#L32
>>>
>>> If I read that script correctly, it would fail to boot with
>>> fdtfile=marvell/armada-3720-espressobin.dtb...

It probably would fall back to the /boot/dtb-$version symlinks...


>> Support for installing in vendor subdirs was added to flash-kernel 3.91
>> from 2018, and I believe the vendor subdirs are included in the
>> debian-installer boot media as well.
>
> alright, but if the vendor path is missing from flash-kernel's db, 
> everything silently works with a flattened tree. See attached patch, now 
> it works here too :)

Yes, I believe this was intentional to smooth the transition without
breaking booting for some machines...


> Before:
> /boot/dtbs/4.19.0-10-arm64/armada-3720-espressobin.dtb
> After:
> /boot/dtbs/4.19.0-10-arm64/marvell/armada-3720-espressobin.dtb
>
> Thanks,
> Andre
> From 9565a3a066f59258886ad1216ce957d63fd390cc Mon Sep 17 00:00:00 2001
> From: Andre Heider 
> Date: Thu, 3 Sep 2020 21:33:18 +0200
> Subject: [PATCH] Fix missing vendor subdirs for arm64 boards.
>
> The subdir is required for installing the fdt file to the correct path,
> which is a prerequisite for a boot loader provided $fdtfile.
> ---
>  db/all.db | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/db/all.db b/db/all.db
> index 16f9606..d7303f7 100644
> --- a/db/all.db
> +++ b/db/all.db
> @@ -487,7 +487,7 @@ Required-Packages: u-boot-tools
>  Bootloader-Sets-Incorrect-Root: yes
>  
>  Machine: Globalscale Marvell ESPRESSOBin Board
> -DTB-Id: armada-3720-espressobin.dtb
> +DTB-Id: marvell/armada-3720-espressobin.dtb
>  Boot-Script-Path: /boot/boot.scr
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
> @@ -874,7 +874,7 @@ Required-Packages: u-boot-tools
>  
>  Machine: Marvell Armada 8040 DB board
>  Kernel-Flavors: arm64
> -DTB-Id: armada-8040-db.dtb
> +DTB-Id: marvell/armada-8040-db.dtb
>  Boot-Script-Path: /boot/boot.scr
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
> @@ -1186,7 +1186,7 @@ Required-Packages: u-boot-tools
>  
>  Machine: Olimex A64 Teres-I
>  Kernel-Flavors: arm64
> -DTB-Id: sun50i-a64-teres-i.dtb
> +DTB-Id: allwinner/sun50i-a64-teres-i.dtb
>  Boot-Script-Path: /boot/boot.scr
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
> @@ -1345,7 +1345,7 @@ Required-Packages: u-boot-tools
>  
>  Machine: Purism Librem 5 devkit
>  Kernel-Flavors: arm64
> -DTB-Id: imx8mq-librem5-devkit.dtb
> +DTB-Id: freescale/imx8mq-librem5-devkit.dtb
>  Boot-Script-Path: /boot/boot.scr
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
> -- 
> 2.20.1


live well,
  vagrant


signature.asc
Description: PGP signature


Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Dennis Gilmore
On Thu, Sep 3, 2020 at 3:24 PM Stephen Warren  wrote:
>
> On 9/3/20 2:14 PM, Dennis Gilmore wrote:
> > On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren  wrote:
> >>
> >> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> >>> When testing builds provided in 
> >>> https://github.com/openwrt/openwrt/pull/3360
> >>> I discovered that fdtfile was not set and as a result the firmware was not
> >>> functional. So I am documenting what is needed.
> >>>
> >>> Signed-off-by: Dennis Gilmore 
> >>>
> >>> Cc: Atish Patra 
> >>> Cc: Lukas Auer 
> >>> Cc: Tom Rini 
> >>> Cc: Masahiro Yamada 
> >>> Cc: Vagrant Cascadian 
> >>> Cc: Stephen Warren 
> >>> Cc: Karsten Merker 
> >>> ---
> >>>  doc/README.distro | 8 
> >>>  1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/doc/README.distro b/doc/README.distro
> >>> index 5076bebd18..3eb70aeb14 100644
> >>> --- a/doc/README.distro
> >>> +++ b/doc/README.distro
> >>> @@ -224,6 +224,14 @@ fdt_addr_r:
> >>>
> >>>A size of 1MB for the FDT/DTB seems reasonable.
> >>>
> >>> +fdtfile:
> >>> +
> >>> +  Mandatory. the name of the DTB file for the specific board for instance
> >>> +  the espressobin v5 board the value is 
> >>> "marvell/armada-3720-espressobin.dtb"
> >>> +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the 
> >>> case of
> >>> +  a board providing its firmware based DTB this value can be used to 
> >>> override
> >>> +  the DTB with a different DTB.
> >>
> >> IIRC this variable isn't mandatory; if the DT filename follows expected
> >> ${soc}-${board}.dtb naming, then U-Boot has a default value that will
> >> work without the user or U-Boot author having to manually set this 
> >> variable.
> >>
> >> So it's certainly mandatory that U-Boot know this value at runtime, but
> >> perhaps the text should be expanded to indicate that sometimes U-Boot
> >> can provide the value itself, but sometimes the variable needs to be set?
> >
> > in include/config_distro_bootcmd.h we have the following
> > /*
> >  * On 32bit ARM systems there is a reasonable number of systems that follow
> >  * the $soc-$board$boardver.dtb name scheme for their device trees. Use that
> >  * scheme if we don't have an explicit fdtfile variable.
> >  */
> > #define BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
> > "if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "   \
> >   "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; "   \
> > "fi; "
> > #else
> > #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
> > #endif
> >
> > that schema is not true on AArch64 and the method only works with efi
> > booting. I will update the text to list out the conditions you could
> > get away with not setting the variable
>
> I was thinking more of cmd/pxe_utils.c:label_boot(), which covers the
> extlinux.conf rather then EFI case. This certainly applies to both 32-
> and 64-bit Tegra systems at least.
>
> Specifically:
> >f1 = env_get("fdtfile");
> > if (f1) {
> > f2 = "";
> > f3 = "";
> > f4 = "";
> > } else {
> > /*
> >  * For complex cases where this code doesn't
> >  * generate the correct filename, the board
> >  * code should set $fdtfile during early 
> > boot,
> >  * or the boot scripts should set $fdtfile
> >  * before invoking "pxe" or "sysboot".
> >  */
> > f1 = env_get("soc");
> > f2 = "-";
> > f3 = env_get("board");
> > f4 = ".dtb";
> > }

That still only covers the 32-bit case, at least unless the OS is
removing the vendor directory from the dtbs. At least for fedora on
aarch64 we leave the vendor directories in place

ls /boot/dtb/
allwinner  amlogic  arm   cavium hisilicon  nvidia  rockchip
amdapm  broadcom  freescale  marvellqcomxilinx

though fedora is only supporting efi on AArch64

Dennis


Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Stephen Warren
On 9/3/20 2:14 PM, Dennis Gilmore wrote:
> On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren  wrote:
>>
>> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
>>> When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
>>> I discovered that fdtfile was not set and as a result the firmware was not
>>> functional. So I am documenting what is needed.
>>>
>>> Signed-off-by: Dennis Gilmore 
>>>
>>> Cc: Atish Patra 
>>> Cc: Lukas Auer 
>>> Cc: Tom Rini 
>>> Cc: Masahiro Yamada 
>>> Cc: Vagrant Cascadian 
>>> Cc: Stephen Warren 
>>> Cc: Karsten Merker 
>>> ---
>>>  doc/README.distro | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/doc/README.distro b/doc/README.distro
>>> index 5076bebd18..3eb70aeb14 100644
>>> --- a/doc/README.distro
>>> +++ b/doc/README.distro
>>> @@ -224,6 +224,14 @@ fdt_addr_r:
>>>
>>>A size of 1MB for the FDT/DTB seems reasonable.
>>>
>>> +fdtfile:
>>> +
>>> +  Mandatory. the name of the DTB file for the specific board for instance
>>> +  the espressobin v5 board the value is 
>>> "marvell/armada-3720-espressobin.dtb"
>>> +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case 
>>> of
>>> +  a board providing its firmware based DTB this value can be used to 
>>> override
>>> +  the DTB with a different DTB.
>>
>> IIRC this variable isn't mandatory; if the DT filename follows expected
>> ${soc}-${board}.dtb naming, then U-Boot has a default value that will
>> work without the user or U-Boot author having to manually set this variable.
>>
>> So it's certainly mandatory that U-Boot know this value at runtime, but
>> perhaps the text should be expanded to indicate that sometimes U-Boot
>> can provide the value itself, but sometimes the variable needs to be set?
> 
> in include/config_distro_bootcmd.h we have the following
> /*
>  * On 32bit ARM systems there is a reasonable number of systems that follow
>  * the $soc-$board$boardver.dtb name scheme for their device trees. Use that
>  * scheme if we don't have an explicit fdtfile variable.
>  */
> #define BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
> "if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "   \
>   "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; "   \
> "fi; "
> #else
> #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
> #endif
> 
> that schema is not true on AArch64 and the method only works with efi
> booting. I will update the text to list out the conditions you could
> get away with not setting the variable

I was thinking more of cmd/pxe_utils.c:label_boot(), which covers the
extlinux.conf rather then EFI case. This certainly applies to both 32-
and 64-bit Tegra systems at least.

Specifically:
>f1 = env_get("fdtfile");
> if (f1) {
> f2 = "";
> f3 = "";
> f4 = "";
> } else {
> /*
>  * For complex cases where this code doesn't
>  * generate the correct filename, the board
>  * code should set $fdtfile during early boot,
>  * or the boot scripts should set $fdtfile
>  * before invoking "pxe" or "sysboot".
>  */
> f1 = env_get("soc");
> f2 = "-";
> f3 = env_get("board");
> f4 = ".dtb";
> }


Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Dennis Gilmore
On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren  wrote:
>
> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> > When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
> > I discovered that fdtfile was not set and as a result the firmware was not
> > functional. So I am documenting what is needed.
> >
> > Signed-off-by: Dennis Gilmore 
> >
> > Cc: Atish Patra 
> > Cc: Lukas Auer 
> > Cc: Tom Rini 
> > Cc: Masahiro Yamada 
> > Cc: Vagrant Cascadian 
> > Cc: Stephen Warren 
> > Cc: Karsten Merker 
> > ---
> >  doc/README.distro | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/doc/README.distro b/doc/README.distro
> > index 5076bebd18..3eb70aeb14 100644
> > --- a/doc/README.distro
> > +++ b/doc/README.distro
> > @@ -224,6 +224,14 @@ fdt_addr_r:
> >
> >A size of 1MB for the FDT/DTB seems reasonable.
> >
> > +fdtfile:
> > +
> > +  Mandatory. the name of the DTB file for the specific board for instance
> > +  the espressobin v5 board the value is 
> > "marvell/armada-3720-espressobin.dtb"
> > +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case 
> > of
> > +  a board providing its firmware based DTB this value can be used to 
> > override
> > +  the DTB with a different DTB.
>
> IIRC this variable isn't mandatory; if the DT filename follows expected
> ${soc}-${board}.dtb naming, then U-Boot has a default value that will
> work without the user or U-Boot author having to manually set this variable.
>
> So it's certainly mandatory that U-Boot know this value at runtime, but
> perhaps the text should be expanded to indicate that sometimes U-Boot
> can provide the value itself, but sometimes the variable needs to be set?

in include/config_distro_bootcmd.h we have the following
/*
 * On 32bit ARM systems there is a reasonable number of systems that follow
 * the $soc-$board$boardver.dtb name scheme for their device trees. Use that
 * scheme if we don't have an explicit fdtfile variable.
 */
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
"if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "   \
  "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; "   \
"fi; "
#else
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK
#endif

that schema is not true on AArch64 and the method only works with efi
booting. I will update the text to list out the conditions you could
get away with not setting the variable

Dennis


Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Andre Heider

Hi Vagrant,

On 03/09/2020 20:59, Vagrant Cascadian wrote:

On 2020-09-03, Andre Heider wrote:

On 03/09/2020 18:40, Dennis Gilmore wrote:

When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
functional. So I am documenting what is needed.

Signed-off-by: Dennis Gilmore 

Cc: Atish Patra 
Cc: Lukas Auer 
Cc: Tom Rini 
Cc: Masahiro Yamada 
Cc: Vagrant Cascadian 
Cc: Stephen Warren 
Cc: Karsten Merker 
---
   doc/README.distro | 8 
   1 file changed, 8 insertions(+)

diff --git a/doc/README.distro b/doc/README.distro
index 5076bebd18..3eb70aeb14 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -224,6 +224,14 @@ fdt_addr_r:
   
 A size of 1MB for the FDT/DTB seems reasonable.
   
+fdtfile:

+
+  Mandatory. the name of the DTB file for the specific board for instance
+  the espressobin v5 board the value is "marvell/armada-3720-espressobin.dtb"
+  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
+  a board providing its firmware based DTB this value can be used to override
+  the DTB with a different DTB.


Thanks for documenting this!

With my Debian hat on...

Reviewed-by: Vagrant Cascadian 



is that really supposed to include the vendor subdir on arm64?


Yes.



If so, adding fdtfile like that would break booting debian using its
flash-image. It installs dtbs without that subdir into /boot:
/boot/dtbs/4.19.0-9-arm64/armada-3720-espressobin.dtb

But it already supports $fdtfile:
https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/arm64/bootscr.uboot-generic#L32

If I read that script correctly, it would fail to boot with
fdtfile=marvell/armada-3720-espressobin.dtb...


Support for installing in vendor subdirs was added to flash-kernel 3.91
from 2018, and I believe the vendor subdirs are included in the
debian-installer boot media as well.


alright, but if the vendor path is missing from flash-kernel's db, 
everything silently works with a flattened tree. See attached patch, now 
it works here too :)


Before:
/boot/dtbs/4.19.0-10-arm64/armada-3720-espressobin.dtb
After:
/boot/dtbs/4.19.0-10-arm64/marvell/armada-3720-espressobin.dtb

Thanks,
Andre
>From 9565a3a066f59258886ad1216ce957d63fd390cc Mon Sep 17 00:00:00 2001
From: Andre Heider 
Date: Thu, 3 Sep 2020 21:33:18 +0200
Subject: [PATCH] Fix missing vendor subdirs for arm64 boards.

The subdir is required for installing the fdt file to the correct path,
which is a prerequisite for a boot loader provided $fdtfile.
---
 db/all.db | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/db/all.db b/db/all.db
index 16f9606..d7303f7 100644
--- a/db/all.db
+++ b/db/all.db
@@ -487,7 +487,7 @@ Required-Packages: u-boot-tools
 Bootloader-Sets-Incorrect-Root: yes
 
 Machine: Globalscale Marvell ESPRESSOBin Board
-DTB-Id: armada-3720-espressobin.dtb
+DTB-Id: marvell/armada-3720-espressobin.dtb
 Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
@@ -874,7 +874,7 @@ Required-Packages: u-boot-tools
 
 Machine: Marvell Armada 8040 DB board
 Kernel-Flavors: arm64
-DTB-Id: armada-8040-db.dtb
+DTB-Id: marvell/armada-8040-db.dtb
 Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
@@ -1186,7 +1186,7 @@ Required-Packages: u-boot-tools
 
 Machine: Olimex A64 Teres-I
 Kernel-Flavors: arm64
-DTB-Id: sun50i-a64-teres-i.dtb
+DTB-Id: allwinner/sun50i-a64-teres-i.dtb
 Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
@@ -1345,7 +1345,7 @@ Required-Packages: u-boot-tools
 
 Machine: Purism Librem 5 devkit
 Kernel-Flavors: arm64
-DTB-Id: imx8mq-librem5-devkit.dtb
+DTB-Id: freescale/imx8mq-librem5-devkit.dtb
 Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
-- 
2.20.1



Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Stephen Warren
On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
> I discovered that fdtfile was not set and as a result the firmware was not
> functional. So I am documenting what is needed.
> 
> Signed-off-by: Dennis Gilmore 
> 
> Cc: Atish Patra 
> Cc: Lukas Auer 
> Cc: Tom Rini 
> Cc: Masahiro Yamada 
> Cc: Vagrant Cascadian 
> Cc: Stephen Warren 
> Cc: Karsten Merker 
> ---
>  doc/README.distro | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/README.distro b/doc/README.distro
> index 5076bebd18..3eb70aeb14 100644
> --- a/doc/README.distro
> +++ b/doc/README.distro
> @@ -224,6 +224,14 @@ fdt_addr_r:
>  
>A size of 1MB for the FDT/DTB seems reasonable.
>  
> +fdtfile:
> +
> +  Mandatory. the name of the DTB file for the specific board for instance
> +  the espressobin v5 board the value is "marvell/armada-3720-espressobin.dtb"
> +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
> +  a board providing its firmware based DTB this value can be used to override
> +  the DTB with a different DTB.

IIRC this variable isn't mandatory; if the DT filename follows expected
${soc}-${board}.dtb naming, then U-Boot has a default value that will
work without the user or U-Boot author having to manually set this variable.

So it's certainly mandatory that U-Boot know this value at runtime, but
perhaps the text should be expanded to indicate that sometimes U-Boot
can provide the value itself, but sometimes the variable needs to be set?


Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Edgar E. Iglesias
On Thu, Sep 03, 2020 at 01:10:48PM -0600, Stephen Warren wrote:
> On 9/3/20 1:07 PM, Edgar E. Iglesias wrote:
> > On Thu, Sep 03, 2020 at 09:45:39AM -0600, Stephen Warren wrote:
> >> On 9/3/20 7:40 AM, André Przywara wrote:
> >>> On 03/09/2020 14:35, Michal Simek wrote:
> 
> 
>  On 02. 09. 20 18:34, Stephen Warren wrote:
> > On 9/2/20 5:15 AM, Michal Simek wrote:
> >> From: "Edgar E. Iglesias" 
> >>
> >> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
> >> compilation error is shown:
> >> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
> >> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol 
> >> `__rel_dyn_end'
> >> defined in .bss_start section in u-boot.
> >>
> >> It is caused by adr instruction which permits the calculation of any 
> >> byte
> >> address within +- 1MB of the current PC.
> >> Because U-Boot is bigger then 1MB calculation is failing.
> >>
> >> The patch is using adrp/add instructions where adrp shifts a signed, 
> >> 21-bit
> >> immediate left by 12 bits (4k page), adds it to the value of the 
> >> program
> >> counter with the bottom 12 bits cleared to zero. Then add instruction
> >> provides the lower 12 bits which is offset within 4k page.
> >> These two instructions together compose full 32bit offset which should 
> >> be
> >> more then enough to cover the whole u-boot size.
> >
> >> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> >
> >> @@ -67,8 +67,10 @@ pie_fixup:
> >>adr x0, _start  /* x0 <- Runtime value of 
> >> _start */
> >>ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start 
> >> */
> >>sub x9, x0, x1  /* x9 <- Run-vs-link offset */
> >> -  adr x2, __rel_dyn_start /* x2 <- Runtime 
> >> &__rel_dyn_start */
> >> -  adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end 
> >> */
> >> +  adrpx2, __rel_dyn_start /* x2 <- Runtime 
> >> &__rel_dyn_start */
> >> +  add x2, x2, #:lo12:__rel_dyn_start
> >> +  adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end 
> >> */
> >> +  add x3, x3, #:lo12:__rel_dyn_end
> >>  pie_fix_loop:
> >>ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, 
> >> fixup) */
> >>ldr x4, [x2], #8/* x4 <- addend */
> >
> > There are likely a bunch of other places in the code that need updating
> > too; take a look at commit 49e93875a62f "arm64: support running at addr
> > other than linked to" (which introduced the code above) to find other
> > places with similar instruction sequences that almost certainly need
> > updating.
> >
> 
>  I didn't hit any issue to have a need to update them. Definitely worth
>  to check that locations too.
> >>>
> >>> So I thought the same, so I checked at least this file. And while there
> >>> are other "adr" instructions, they only go to nearby labels, so don't
> >>> need to be pumped up.
> >>> But I will try to grep for more cases as well.
> >>
> >>
> >> So in the patch I linked to, what about the added ard instructions in
> >> arch/arm/lib/crt0_64.S and arch/arm/lib/relocate_64.S?
> >>
> >> Perhaps that code gets linked more towards the middle of U-Boot than the
> >> code you're fixing in start.S, so the max 1M offset just happens to
> >> reach all the relevant symbols and relocations that are in your current
> >> binary, but if your binary gets a little larger (e.g. goes from 1.05M to
> >> 2M say) that code will fail in the same way?
> > 
> > Yes, those were apparently already corrected by Ibai:
> > https://github.com/u-boot/u-boot/commit/98ffbb78e12646a1d06236ad6a1893217f255aae#diff-4f864f65dc6b6f2535a5d252b7c9fcc7
> 
> Ah OK.
> 
> So I guess this means that in practice, U-Boot already has the
> limitation that the load (and relocation target?) address must be
> 4K-aligned, since it uses the same instruction sequence we're
> discusssing here.

Apparently, yes.

Anyway, we'll submit a patch tomorrow with the early trapping if not
aligned.

Cheers,
Edgar


Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Stephen Warren
On 9/3/20 1:07 PM, Edgar E. Iglesias wrote:
> On Thu, Sep 03, 2020 at 09:45:39AM -0600, Stephen Warren wrote:
>> On 9/3/20 7:40 AM, André Przywara wrote:
>>> On 03/09/2020 14:35, Michal Simek wrote:


 On 02. 09. 20 18:34, Stephen Warren wrote:
> On 9/2/20 5:15 AM, Michal Simek wrote:
>> From: "Edgar E. Iglesias" 
>>
>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>> compilation error is shown:
>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>> defined in .bss_start section in u-boot.
>>
>> It is caused by adr instruction which permits the calculation of any byte
>> address within +- 1MB of the current PC.
>> Because U-Boot is bigger then 1MB calculation is failing.
>>
>> The patch is using adrp/add instructions where adrp shifts a signed, 
>> 21-bit
>> immediate left by 12 bits (4k page), adds it to the value of the program
>> counter with the bottom 12 bits cleared to zero. Then add instruction
>> provides the lower 12 bits which is offset within 4k page.
>> These two instructions together compose full 32bit offset which should be
>> more then enough to cover the whole u-boot size.
>
>> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
>
>> @@ -67,8 +67,10 @@ pie_fixup:
>>  adr x0, _start  /* x0 <- Runtime value of 
>> _start */
>>  ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start 
>> */
>>  sub x9, x0, x1  /* x9 <- Run-vs-link offset */
>> -adr x2, __rel_dyn_start /* x2 <- Runtime 
>> &__rel_dyn_start */
>> -adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end 
>> */
>> +adrpx2, __rel_dyn_start /* x2 <- Runtime 
>> &__rel_dyn_start */
>> +add x2, x2, #:lo12:__rel_dyn_start
>> +adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end 
>> */
>> +add x3, x3, #:lo12:__rel_dyn_end
>>  pie_fix_loop:
>>  ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, 
>> fixup) */
>>  ldr x4, [x2], #8/* x4 <- addend */
>
> There are likely a bunch of other places in the code that need updating
> too; take a look at commit 49e93875a62f "arm64: support running at addr
> other than linked to" (which introduced the code above) to find other
> places with similar instruction sequences that almost certainly need
> updating.
>

 I didn't hit any issue to have a need to update them. Definitely worth
 to check that locations too.
>>>
>>> So I thought the same, so I checked at least this file. And while there
>>> are other "adr" instructions, they only go to nearby labels, so don't
>>> need to be pumped up.
>>> But I will try to grep for more cases as well.
>>
>>
>> So in the patch I linked to, what about the added ard instructions in
>> arch/arm/lib/crt0_64.S and arch/arm/lib/relocate_64.S?
>>
>> Perhaps that code gets linked more towards the middle of U-Boot than the
>> code you're fixing in start.S, so the max 1M offset just happens to
>> reach all the relevant symbols and relocations that are in your current
>> binary, but if your binary gets a little larger (e.g. goes from 1.05M to
>> 2M say) that code will fail in the same way?
> 
> Yes, those were apparently already corrected by Ibai:
> https://github.com/u-boot/u-boot/commit/98ffbb78e12646a1d06236ad6a1893217f255aae#diff-4f864f65dc6b6f2535a5d252b7c9fcc7

Ah OK.

So I guess this means that in practice, U-Boot already has the
limitation that the load (and relocation target?) address must be
4K-aligned, since it uses the same instruction sequence we're
discusssing here.


Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Edgar E. Iglesias
On Thu, Sep 03, 2020 at 09:45:39AM -0600, Stephen Warren wrote:
> On 9/3/20 7:40 AM, André Przywara wrote:
> > On 03/09/2020 14:35, Michal Simek wrote:
> >>
> >>
> >> On 02. 09. 20 18:34, Stephen Warren wrote:
> >>> On 9/2/20 5:15 AM, Michal Simek wrote:
>  From: "Edgar E. Iglesias" 
> 
>  When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>  compilation error is shown:
>  /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>  truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>  defined in .bss_start section in u-boot.
> 
>  It is caused by adr instruction which permits the calculation of any byte
>  address within +- 1MB of the current PC.
>  Because U-Boot is bigger then 1MB calculation is failing.
> 
>  The patch is using adrp/add instructions where adrp shifts a signed, 
>  21-bit
>  immediate left by 12 bits (4k page), adds it to the value of the program
>  counter with the bottom 12 bits cleared to zero. Then add instruction
>  provides the lower 12 bits which is offset within 4k page.
>  These two instructions together compose full 32bit offset which should be
>  more then enough to cover the whole u-boot size.
> >>>
>  diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> >>>
>  @@ -67,8 +67,10 @@ pie_fixup:
>   adr x0, _start  /* x0 <- Runtime value of 
>  _start */
>   ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start 
>  */
>   sub x9, x0, x1  /* x9 <- Run-vs-link offset */
>  -adr x2, __rel_dyn_start /* x2 <- Runtime 
>  &__rel_dyn_start */
>  -adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end 
>  */
>  +adrpx2, __rel_dyn_start /* x2 <- Runtime 
>  &__rel_dyn_start */
>  +add x2, x2, #:lo12:__rel_dyn_start
>  +adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end 
>  */
>  +add x3, x3, #:lo12:__rel_dyn_end
>   pie_fix_loop:
>   ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, 
>  fixup) */
>   ldr x4, [x2], #8/* x4 <- addend */
> >>>
> >>> There are likely a bunch of other places in the code that need updating
> >>> too; take a look at commit 49e93875a62f "arm64: support running at addr
> >>> other than linked to" (which introduced the code above) to find other
> >>> places with similar instruction sequences that almost certainly need
> >>> updating.
> >>>
> >>
> >> I didn't hit any issue to have a need to update them. Definitely worth
> >> to check that locations too.
> > 
> > So I thought the same, so I checked at least this file. And while there
> > are other "adr" instructions, they only go to nearby labels, so don't
> > need to be pumped up.
> > But I will try to grep for more cases as well.
> 
> 
> So in the patch I linked to, what about the added ard instructions in
> arch/arm/lib/crt0_64.S and arch/arm/lib/relocate_64.S?
> 
> Perhaps that code gets linked more towards the middle of U-Boot than the
> code you're fixing in start.S, so the max 1M offset just happens to
> reach all the relevant symbols and relocations that are in your current
> binary, but if your binary gets a little larger (e.g. goes from 1.05M to
> 2M say) that code will fail in the same way?

Yes, those were apparently already corrected by Ibai:
https://github.com/u-boot/u-boot/commit/98ffbb78e12646a1d06236ad6a1893217f255aae#diff-4f864f65dc6b6f2535a5d252b7c9fcc7

Cheers,
Edgar


Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Vagrant Cascadian
On 2020-09-03, Andre Heider wrote:
> On 03/09/2020 18:40, Dennis Gilmore wrote:
>> When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
>> I discovered that fdtfile was not set and as a result the firmware was not
>> functional. So I am documenting what is needed.
>> 
>> Signed-off-by: Dennis Gilmore 
>> 
>> Cc: Atish Patra 
>> Cc: Lukas Auer 
>> Cc: Tom Rini 
>> Cc: Masahiro Yamada 
>> Cc: Vagrant Cascadian 
>> Cc: Stephen Warren 
>> Cc: Karsten Merker 
>> ---
>>   doc/README.distro | 8 
>>   1 file changed, 8 insertions(+)
>> 
>> diff --git a/doc/README.distro b/doc/README.distro
>> index 5076bebd18..3eb70aeb14 100644
>> --- a/doc/README.distro
>> +++ b/doc/README.distro
>> @@ -224,6 +224,14 @@ fdt_addr_r:
>>   
>> A size of 1MB for the FDT/DTB seems reasonable.
>>   
>> +fdtfile:
>> +
>> +  Mandatory. the name of the DTB file for the specific board for instance
>> +  the espressobin v5 board the value is 
>> "marvell/armada-3720-espressobin.dtb"
>> +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
>> +  a board providing its firmware based DTB this value can be used to 
>> override
>> +  the DTB with a different DTB.

Thanks for documenting this!

With my Debian hat on...

Reviewed-by: Vagrant Cascadian 


> is that really supposed to include the vendor subdir on arm64?

Yes.


> If so, adding fdtfile like that would break booting debian using its 
> flash-image. It installs dtbs without that subdir into /boot:
> /boot/dtbs/4.19.0-9-arm64/armada-3720-espressobin.dtb
>
> But it already supports $fdtfile:
> https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/arm64/bootscr.uboot-generic#L32
>
> If I read that script correctly, it would fail to boot with 
> fdtfile=marvell/armada-3720-espressobin.dtb...

Support for installing in vendor subdirs was added to flash-kernel 3.91
from 2018, and I believe the vendor subdirs are included in the
debian-installer boot media as well.


live well,
  vagrant


signature.asc
Description: PGP signature


Re: [PATCH] spl: Avoid printing boot device if silent console is enabled

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 02:25:15PM -0300, Otavio Salvador wrote:

> Signed-off-by: Otavio Salvador 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-usb/master

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:

> Mostly DFU fixes and r8152 fixes below:
> 
> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
> 
>   MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
> 17:11:24 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 293a6dfeb96129abebf1ad927fa9aedf03a66d34:
> 
>   fastboot: getvar: fix partition-size return value (2020-09-01 14:47:43
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-sh/master

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 02:15:10PM +0200, Marek Vasut wrote:

> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
> 
>   MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
> 17:11:24 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to f5ba5c90d4b9c4d691a62eaca47dc095eefba8b1:
> 
>   serial: sh: Improve FIFO empty check on RX (2020-09-01 14:46:41 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [GIT PULL] SoCFPGA change for v2020-10-rc4

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 06:53:22AM +, Tan, Ley Foon wrote:

> Hi Tom
> 
> Please pull one change for u-boot SoCFPGA.
> 
> Regards
> Ley Foon
> 
> 
> The following changes since commit 7149077353ef4837ab2fcdce5d7e52c5ed4b026a:
> 
>   Azure/GitLab: Update to latest Docker container (2020-09-02 09:22:29 -0400)
> 
> are available in the Git repository at:
> 
>   https://github.com/lftan/u-boot.git for-tom
> 
> for you to fetch changes up to 6b6307ed22121a38c5b1a5198e737e78b7135312:
> 
>   arm: socfpga: soc64: Check FPGA Config status register before bridge reset 
> (2020-09-03 11:26:07 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 07:50:32PM +0200, Andre Heider wrote:
> Hi Dennis,
> 
> On 03/09/2020 18:40, Dennis Gilmore wrote:
> > When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
> > I discovered that fdtfile was not set and as a result the firmware was not
> > functional. So I am documenting what is needed.
> > 
> > Signed-off-by: Dennis Gilmore 
> > 
> > Cc: Atish Patra 
> > Cc: Lukas Auer 
> > Cc: Tom Rini 
> > Cc: Masahiro Yamada 
> > Cc: Vagrant Cascadian 
> > Cc: Stephen Warren 
> > Cc: Karsten Merker 
> > ---
> >   doc/README.distro | 8 
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/doc/README.distro b/doc/README.distro
> > index 5076bebd18..3eb70aeb14 100644
> > --- a/doc/README.distro
> > +++ b/doc/README.distro
> > @@ -224,6 +224,14 @@ fdt_addr_r:
> > A size of 1MB for the FDT/DTB seems reasonable.
> > +fdtfile:
> > +
> > +  Mandatory. the name of the DTB file for the specific board for instance
> > +  the espressobin v5 board the value is 
> > "marvell/armada-3720-espressobin.dtb"
> > +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case 
> > of
> > +  a board providing its firmware based DTB this value can be used to 
> > override
> > +  the DTB with a different DTB.
> 
> is that really supposed to include the vendor subdir on arm64?
> 
> If so, adding fdtfile like that would break booting debian using its
> flash-image. It installs dtbs without that subdir into /boot:
> /boot/dtbs/4.19.0-9-arm64/armada-3720-espressobin.dtb
> 
> But it already supports $fdtfile:
> https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/arm64/bootscr.uboot-generic#L32
> 
> If I read that script correctly, it would fail to boot with
> fdtfile=marvell/armada-3720-espressobin.dtb...

Ugh.  I thought vendors were not supposed to flatten the dtbs as
installed.  Did that change?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Andre Heider

Hi Dennis,

On 03/09/2020 18:40, Dennis Gilmore wrote:

When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
functional. So I am documenting what is needed.

Signed-off-by: Dennis Gilmore 

Cc: Atish Patra 
Cc: Lukas Auer 
Cc: Tom Rini 
Cc: Masahiro Yamada 
Cc: Vagrant Cascadian 
Cc: Stephen Warren 
Cc: Karsten Merker 
---
  doc/README.distro | 8 
  1 file changed, 8 insertions(+)

diff --git a/doc/README.distro b/doc/README.distro
index 5076bebd18..3eb70aeb14 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -224,6 +224,14 @@ fdt_addr_r:
  
A size of 1MB for the FDT/DTB seems reasonable.
  
+fdtfile:

+
+  Mandatory. the name of the DTB file for the specific board for instance
+  the espressobin v5 board the value is "marvell/armada-3720-espressobin.dtb"
+  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
+  a board providing its firmware based DTB this value can be used to override
+  the DTB with a different DTB.


is that really supposed to include the vendor subdir on arm64?

If so, adding fdtfile like that would break booting debian using its 
flash-image. It installs dtbs without that subdir into /boot:

/boot/dtbs/4.19.0-9-arm64/armada-3720-espressobin.dtb

But it already supports $fdtfile:
https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/arm64/bootscr.uboot-generic#L32

If I read that script correctly, it would fail to boot with 
fdtfile=marvell/armada-3720-espressobin.dtb...


Regards,
Andre


[PATCH] spl: Avoid printing boot device if silent console is enabled

2020-09-03 Thread Otavio Salvador
Signed-off-by: Otavio Salvador 
---

 common/spl/spl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 4840d1d367..63c48fbf33 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -552,7 +552,9 @@ static int boot_from_devices(struct spl_image_info 
*spl_image,
struct spl_image_loader *loader;
 
loader = spl_ll_find_loader(spl_boot_list[i]);
-#if defined(CONFIG_SPL_SERIAL_SUPPORT) && defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if defined(CONFIG_SPL_SERIAL_SUPPORT) \
+&& defined(CONFIG_SPL_LIBCOMMON_SUPPORT)\
+&& !defined(CONFIG_SILENT_CONSOLE)
if (loader)
printf("Trying to boot from %s\n", loader->name);
else
-- 
2.28.0



[PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

2020-09-03 Thread Dennis Gilmore
When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
functional. So I am documenting what is needed.

Signed-off-by: Dennis Gilmore 

Cc: Atish Patra 
Cc: Lukas Auer 
Cc: Tom Rini 
Cc: Masahiro Yamada 
Cc: Vagrant Cascadian 
Cc: Stephen Warren 
Cc: Karsten Merker 
---
 doc/README.distro | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/README.distro b/doc/README.distro
index 5076bebd18..3eb70aeb14 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -224,6 +224,14 @@ fdt_addr_r:
 
   A size of 1MB for the FDT/DTB seems reasonable.
 
+fdtfile:
+
+  Mandatory. the name of the DTB file for the specific board for instance
+  the espressobin v5 board the value is "marvell/armada-3720-espressobin.dtb"
+  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
+  a board providing its firmware based DTB this value can be used to override
+  the DTB with a different DTB.
+
 ramdisk_addr_r:
 
   Mandatory. The location in RAM where the initial ramdisk will be loaded to
-- 
2.28.0



Re: U-Boot fails dfu on edison

2020-09-03 Thread Andy Shevchenko
On Thu, Sep 03, 2020 at 06:05:44PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 03, 2020 at 08:21:23AM -0600, Simon Glass wrote:
> > On Thu, 3 Sep 2020 at 07:51, Andy Shevchenko  
> > wrote:
> > > On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
> > >  wrote:
> > > > On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:
> 
> ...
> 
> > > > Hmm... Have you read this [1]? It may give some hints I think.
> > > >
> > > > [1]: https://edison-fw.github.io/edison-wiki/u-boot-update (look into 
> > > > known-bugs section)
> > > >
> > > > > Any ideas please?
> > > >
> > > > See above.
> > >
> > > Just in case my script [2] to prepare a U-Boot image file suitable for 
> > > xFSTK.
> > >
> > > [2]: https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
> > 
> > Thanks, that gets me a bit closer. Here are my steps:
> > 
> > 1. Start with the original 2014 U-Boot from 'flashall.sh --recovery'
> > 2. Boot it and use dfu-util to flash the latest 2020 U-Boot as per 
> > edison.rst
> > 3. Set env vars as guessed from the link you provided:
> > 
> > setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart
> > 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0 part 0
> > 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0 4;boot part
> > 0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz fat 0
> > 7;initrd fat 0 7"
> > setenv do_dfu_alt_info_ifwi 'setenv dfu_alt_info "ifwi${hardware_id}
> > raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2"'
> > setenv do_dfu_alt_info_mmc 'setenv dfu_alt_info "ifwi${hardware_id}
> > raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0
> > part 0 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0
> > 4;boot part 0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz
> > fat 0 7;initrd fat 0 7"'
> > setenv do_flash_ifwi 'run do_dfu_alt_info_ifwi ; dfu 0 raw 3'
> > setenv do_force_flash_os 'run do_dfu_alt_info_mmc ; sleep 1 ; setenv
> > do_flash_os_done 1 ; saveenv ; dfu 0 raw 3'
> 
> ^^^
> 
> > 4. Reboot and see:
> > 
> > U-Boot 2020.10-rc3-00012-g9f04a634ef3 (Sep 03 2020 - 07:06:30 -0600)
> > 
> > CPU:   Genuine Intel(R) CPU   4000  @  500MHz
> > DRAM:  980.6 MiB
> > WDT:   Started with servicing (60s timeout)
> > MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
> > Loading Environment from MMC... OK
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   No ethernet found.
> > Hit any key to stop autoboot:  0
> > Target:ifwi
> > Partitioning already done...
> > Partitioning already done...
> > Saving Environment to MMC... Writing to redundant MMC(0)... OK
> > dfu_fill_entity: Device raw not (yet) supported!
> 
> > So I am still missing something?
> 
> Yes. You haven't read the Issue #3 [3] mentioned in the known-bug section in 
> [1].
> 
> [3]: https://github.com/intel/edison-u-boot/issues/3

For your convenience copy'n'paste of my comments from [3].

~~~
You need to change mmc word (note that mmcpart word is left untouched) to raw
word in description of partitions. It's done, for example, in
do_dfu_alt_info_mmc environment variable.

Command is kept the same:
dfu 0 mmc 0

~~~
There is no rawpart keyword in DFU if I remember correctly. You need to use
mmcpart instead. I have updated above comment to accent on this.

~~~


-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Stephen Warren
On 9/3/20 7:40 AM, André Przywara wrote:
> On 03/09/2020 14:35, Michal Simek wrote:
>>
>>
>> On 02. 09. 20 18:34, Stephen Warren wrote:
>>> On 9/2/20 5:15 AM, Michal Simek wrote:
 From: "Edgar E. Iglesias" 

 When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
 compilation error is shown:
 /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
 truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
 defined in .bss_start section in u-boot.

 It is caused by adr instruction which permits the calculation of any byte
 address within +- 1MB of the current PC.
 Because U-Boot is bigger then 1MB calculation is failing.

 The patch is using adrp/add instructions where adrp shifts a signed, 21-bit
 immediate left by 12 bits (4k page), adds it to the value of the program
 counter with the bottom 12 bits cleared to zero. Then add instruction
 provides the lower 12 bits which is offset within 4k page.
 These two instructions together compose full 32bit offset which should be
 more then enough to cover the whole u-boot size.
>>>
 diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
>>>
 @@ -67,8 +67,10 @@ pie_fixup:
adr x0, _start  /* x0 <- Runtime value of _start */
ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
sub x9, x0, x1  /* x9 <- Run-vs-link offset */
 -  adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
 -  adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
 +  adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
 +  add x2, x2, #:lo12:__rel_dyn_start
 +  adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
 +  add x3, x3, #:lo12:__rel_dyn_end
  pie_fix_loop:
ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, fixup) */
ldr x4, [x2], #8/* x4 <- addend */
>>>
>>> There are likely a bunch of other places in the code that need updating
>>> too; take a look at commit 49e93875a62f "arm64: support running at addr
>>> other than linked to" (which introduced the code above) to find other
>>> places with similar instruction sequences that almost certainly need
>>> updating.
>>>
>>
>> I didn't hit any issue to have a need to update them. Definitely worth
>> to check that locations too.
> 
> So I thought the same, so I checked at least this file. And while there
> are other "adr" instructions, they only go to nearby labels, so don't
> need to be pumped up.
> But I will try to grep for more cases as well.


So in the patch I linked to, what about the added ard instructions in
arch/arm/lib/crt0_64.S and arch/arm/lib/relocate_64.S?

Perhaps that code gets linked more towards the middle of U-Boot than the
code you're fixing in start.S, so the max 1M offset just happens to
reach all the relevant symbols and relocations that are in your current
binary, but if your binary gets a little larger (e.g. goes from 1.05M to
2M say) that code will fail in the same way?


Re: U-Boot fails dfu on edison

2020-09-03 Thread Andy Shevchenko
On Thu, Sep 03, 2020 at 08:21:23AM -0600, Simon Glass wrote:
> On Thu, 3 Sep 2020 at 07:51, Andy Shevchenko  
> wrote:
> > On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
> >  wrote:
> > > On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:

...

> > > Hmm... Have you read this [1]? It may give some hints I think.
> > >
> > > [1]: https://edison-fw.github.io/edison-wiki/u-boot-update (look into 
> > > known-bugs section)
> > >
> > > > Any ideas please?
> > >
> > > See above.
> >
> > Just in case my script [2] to prepare a U-Boot image file suitable for 
> > xFSTK.
> >
> > [2]: https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
> 
> Thanks, that gets me a bit closer. Here are my steps:
> 
> 1. Start with the original 2014 U-Boot from 'flashall.sh --recovery'
> 2. Boot it and use dfu-util to flash the latest 2020 U-Boot as per edison.rst
> 3. Set env vars as guessed from the link you provided:
> 
> setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart
> 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0 part 0
> 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0 4;boot part
> 0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz fat 0
> 7;initrd fat 0 7"
> setenv do_dfu_alt_info_ifwi 'setenv dfu_alt_info "ifwi${hardware_id}
> raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2"'
> setenv do_dfu_alt_info_mmc 'setenv dfu_alt_info "ifwi${hardware_id}
> raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0
> part 0 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0
> 4;boot part 0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz
> fat 0 7;initrd fat 0 7"'
> setenv do_flash_ifwi 'run do_dfu_alt_info_ifwi ; dfu 0 raw 3'
> setenv do_force_flash_os 'run do_dfu_alt_info_mmc ; sleep 1 ; setenv
> do_flash_os_done 1 ; saveenv ; dfu 0 raw 3'

^^^

> 4. Reboot and see:
> 
> U-Boot 2020.10-rc3-00012-g9f04a634ef3 (Sep 03 2020 - 07:06:30 -0600)
> 
> CPU:   Genuine Intel(R) CPU   4000  @  500MHz
> DRAM:  980.6 MiB
> WDT:   Started with servicing (60s timeout)
> MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
> Loading Environment from MMC... OK
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> Target:ifwi
> Partitioning already done...
> Partitioning already done...
> Saving Environment to MMC... Writing to redundant MMC(0)... OK
> dfu_fill_entity: Device raw not (yet) supported!

> So I am still missing something?

Yes. You haven't read the Issue #3 [3] mentioned in the known-bug section in 
[1].

[3]: https://github.com/intel/edison-u-boot/issues/3

-- 
With Best Regards,
Andy Shevchenko




Re: U-Boot fails dfu on edison

2020-09-03 Thread Simon Glass
Hi Andy,

On Thu, 3 Sep 2020 at 07:51, Andy Shevchenko  wrote:
>
> On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
>  wrote:
> > On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:
>
> ...
>
> > Hmm... Have you read this [1]? It may give some hints I think.
> >
> > [1]: https://edison-fw.github.io/edison-wiki/u-boot-update (look into 
> > known-bugs section)
> >
> > > Any ideas please?
> >
> > See above.
>
> Just in case my script [2] to prepare a U-Boot image file suitable for xFSTK.
>
> [2]: https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f

Thanks, that gets me a bit closer. Here are my steps:

1. Start with the original 2014 U-Boot from 'flashall.sh --recovery'
2. Boot it and use dfu-util to flash the latest 2020 U-Boot as per edison.rst
3. Set env vars as guessed from the link you provided:

setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart
1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0 part 0
1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0 4;boot part
0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz fat 0
7;initrd fat 0 7"
setenv do_dfu_alt_info_ifwi 'setenv dfu_alt_info "ifwi${hardware_id}
raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2"'
setenv do_dfu_alt_info_mmc 'setenv dfu_alt_info "ifwi${hardware_id}
raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0
part 0 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0
4;boot part 0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz
fat 0 7;initrd fat 0 7"'
setenv do_flash_ifwi 'run do_dfu_alt_info_ifwi ; dfu 0 raw 3'
setenv do_force_flash_os 'run do_dfu_alt_info_mmc ; sleep 1 ; setenv
do_flash_os_done 1 ; saveenv ; dfu 0 raw 3'

4. Reboot and see:

U-Boot 2020.10-rc3-00012-g9f04a634ef3 (Sep 03 2020 - 07:06:30 -0600)

CPU:   Genuine Intel(R) CPU   4000  @  500MHz
DRAM:  980.6 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
Loading Environment from MMC... OK
In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Target:ifwi
Partitioning already done...
Partitioning already done...
Saving Environment to MMC... Writing to redundant MMC(0)... OK
dfu_fill_entity: Device raw not (yet) supported!
DFU entities configuration failed!
(partition table does not match dfu_alt_info?)
dfu - Device Firmware Upgrade

Usage:
dfu  [ ] [] [list]
  - device firmware upgrade via 
on device , attached to interface

[] - specify inactivity timeout in seconds
[list] - list available alt settings

Unknown boot mode: boot
## Error: Can't force access to "bootargs_mode"
Saving Environment to MMC... Writing to MMC(0)... OK
Resetting to default boot mode and reboot...
resetting ...


So I am still missing something?

Regards,
Simon


Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Michal Simek



On 03. 09. 20 15:59, Edgar E. Iglesias wrote:
> On Thu, Sep 03, 2020 at 02:52:39PM +0100, André Przywara wrote:
>> On 03/09/2020 14:41, Michal Simek wrote:
>>>
>>>
>>> On 02. 09. 20 20:59, André Przywara wrote:
 On 02/09/2020 16:25, Edgar E. Iglesias wrote:
> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
>> On 02/09/2020 15:53, Edgar E. Iglesias wrote:
>>> On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
 On 02/09/2020 12:15, Michal Simek wrote:
>>
>> Hi,
>>

> From: "Edgar E. Iglesias" 
>
> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
> compilation error is shown:
> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): 
> relocation
> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol 
> `__rel_dyn_end'
> defined in .bss_start section in u-boot.
>
> It is caused by adr instruction which permits the calculation of any 
> byte
> address within +- 1MB of the current PC.
> Because U-Boot is bigger then 1MB calculation is failing.
>
> The patch is using adrp/add instructions where adrp shifts a signed, 
> 21-bit
> immediate left by 12 bits (4k page), adds it to the value of the 
> program
> counter with the bottom 12 bits cleared to zero. Then add instruction
> provides the lower 12 bits which is offset within 4k page.
> These two instructions together compose full 32bit offset which 
> should be
> more then enough to cover the whole u-boot size.
>
> Signed-off-by: Edgar E. Iglesias 
> Signed-off-by: Michal Simek 

 It's a bit scary that you need more than 1MB, but indeed what you do
 below is the canonical pattern to get the full range of PC relative
 addressing (this is used heavily in Trusted Firmware, for instance).

 The only thing to keep in mind is that this assumes that the load
 address of the binary is 4K aligned, so that the low 12 bits of the
 symbol stay the same. I wonder if we should enforce this somehow? But
 the load address is not controlled by the build process (the whole
 purpose of PIE), so that's not doable just in the build system?
>>>
>>> There shouldn't be any need for 4K alignment. Could you elaborate on
>>> why you think there is?
>>
>> That seems to be slightly tricky, and I tried to get some confirmation,
>> but here goes my reasoning. Maybe you can confirm this:
>>
>> - adrp takes the relative offset, but only of the upper 20 bits (because
>> that's all we can encode). It clears the lower 12 bits of the register.
>> - the "add" is not PC relative anymore, so it just takes the lower 12
>> bits of the "absolute" linker symbol.
>
> I was under the impression that this would use a PC-relative lower 12bit
> relocation but you are correct. I dissasembled the result:
>
>   40:   9142add x2, x2, #0x0
> 40: R_AARCH64_ADD_ABS_LO12_NC   __rel_dyn_start
>
>
>
>
>
>> So this assumes that the lower 12 bits of the actual address in memory
>> and the lower 12 bits of the linker's view match.
>> An example:
>> 00024: adrp x0, SYMBOL
>> 00028: add  x0, x0, :lo12:SYMBOL
>>
>> SYMBOL:
>> 42058: ...
>>
>> The toolchain will generate:
>>  adrp x0, #0x42; add x0, x0, #0x058
>>
>> Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at
>> 0x80042858.
>> The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000.
>> The add will just add 0x58, so you end up with x0 being 0x80042058,
>> which is not the right address.
>>
>> Does this make sense?
>
>
> Yes, it makes sense.
>
>>
>>> Perhaps the commit message is a little confusing. The toolchain will
>>> compute the pc-relative offset from this particular location to the
>>> symbol and apply the relocations accordingly.
>>
>> Yes, but the PC relative offset applies only to the upper 20 bits,
>> because it's only adrp that has PC relative semantics.
>>
>>

 Shall we at least document this? I guess typical load address are
 actually quite well aligned, so it might not be an issue in practice.

>
> Yes, probably worth documenting and perhaps an early bail-out if it's not
> the case...

 Documenting sounds good, Kconfig might be a good place, as Michal 
 suggested.

 Bail out: I thought about that, it's very easy to detect at runtime, but
 what then? This is really early, so you could just enter a WFI loop, and
 hope for someone to connect the dots?
 Or can you think of any other way of communicating 

[PATCH v4 4/4] pci: layerscape: add a way of specifying additional iommu mappings

2020-09-03 Thread laurentiu . tudor
From: Laurentiu Tudor 

In the current implementation, u-boot creates iommu mappings only
for PCI devices enumarated at boot time thus does not take into
account more dynamic scenarios such as SR-IOV or PCI hot-plug.
Add an u-boot env var and a device tree property (to be used for
example in more static scenarios such as hardwired PCI endpoints
that get initialized later in the system setup) that would allow
two things:
 - for a SRIOV capable PCI EP identified by its B.D.F specify
   the maximum number of VFs that will ever be created for it
 - for hot-plug case, specify the B.D.F with which the device
   will show up on the PCI bus
More details can be found in the included documentation:
  arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra

Signed-off-by: Laurentiu Tudor 
---
 .../fsl-layerscape/doc/README.pci_iommu_extra |  67 
 drivers/pci/Kconfig   |  12 +
 drivers/pci/pcie_layerscape_fixup.c   | 328 ++
 3 files changed, 407 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra 
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra
new file mode 100644
index 00..43db4d8e94
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra
@@ -0,0 +1,67 @@
+#
+# Copyright 2020 NXP
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+Specifying extra IOMMU mappings for PCI controllers
+
+This feature can be enabled through the PCI_IOMMU_EXTRA_MAPPINGS Kconfig 
option.
+
+The "pci_iommu_extra" env var or "pci-iommu-extra" device tree property (to be
+used for example in more static scenarios such as hardwired PCI endpoints that
+get initialized later in the system setup) allows two things:
+ - for a SRIOV capable PCI EP identified by its B.D.F specify the maximum 
number
+   of VFs that will ever be created for it
+ - for hot-plug case, specify the B.D.F with which the device will show up on
+   the PCI bus
+
+The env var consists of a list of , pairs for a certain pci bus
+identified by its controller's base register address, as defined in the "reg"
+property in the device tree.
+
+pci_iommu_extra = pci@,
+ pci@,...
+
+where:
+  is the base register address of the pci controller for which the
+subsequent , pairs apply
+  identifies to which B.D.F the action applies to
+  can be:
+- "vfs=" to specify that for the PCI EP identified previously by
+  the  to include mappings for  of VFs.
+  The variant "noari_vfs=" is available to disable taking ARI into
+  account.
+- "hp" to specify that on this  there will be a hot-plugged device so
+  it needs a mapping
+The device tree property must be placed under the correct pci controller node
+and only the bdf and action pairs need to be specified, like this:
+
+pci-iommu-extra = "...";
+
+Note: the env var has priority over the device tree property.
+
+For example, given this configuration on bus 6:
+
+=> pci 6
+Scanning PCI devices on bus 6
+BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
+_
+06.00.00   0x8086 0x1572 Network controller  0x00
+06.00.01   0x8086 0x1572 Network controller  0x00
+
+The following u-boot env var will create iommu mappings for 3 VFs for each PF:
+
+=> setenv pci_iommu_extra pci@0x380,6.0.0,vfs=3,6.0.1,vfs=3
+
+For the device tree case, this would be specified like this:
+
+pci-iommu-extra = "6.0.0,vfs=3,6.0.1,vfs=3";
+
+To add an iommu mapping for a hot-plugged device, please see following example:
+
+=> setenv pci_iommu_extra pci@0x380,2.16.0,hp
+
+For the device tree case, this would be specified like this:
+
+pci-iommu-extra = "2.16.0,hp";
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index dd1cc65229..af92784950 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -179,6 +179,18 @@ config PCIE_LAYERSCAPE_RC
  configured to Root Complex mode by clearing the corresponding bit of
  RCW[HOST_AGT_PEX].
 
+config PCI_IOMMU_EXTRA_MAPPINGS
+   bool "Support for specifying extra IOMMU mappings for PCI"
+   depends on PCIE_LAYERSCAPE_RC
+   help
+ Enable support for specifying extra IOMMU mappings for PCI
+ controllers through a special env var called "pci_iommu_extra" or
+ through a device tree property named "pci-iommu-extra" placed in
+ the node describing the PCI controller.
+ The intent is to cover SR-IOV scenarios which need mappings for VFs
+ and PCI hot-plug scenarios. More documentation can be found under:
+   arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra
+
 config PCIE_LAYERSCAPE_EP
bool "Layerscape PCIe Endpoint mode support"
depends on DM_PCI
diff --git a/drivers/pci/pcie_layerscape_fixup.c 
b/drivers/pci/pcie_layerscape_fixup.c
index 

[PATCH v4 3/4] pci: add a few ARI related defines

2020-09-03 Thread laurentiu . tudor
From: Laurentiu Tudor 

Add a few defines related to PCI ARI configuration.

Signed-off-by: Laurentiu Tudor 
---
 include/pci.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/pci.h b/include/pci.h
index 1c5b36617e..d1ccf6c963 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -495,12 +495,18 @@
 #define  PCI_EXP_LNKSTA_DLLLA  0x2000  /* Data Link Layer Link Active */
 #define PCI_EXP_SLTCAP 20  /* Slot Capabilities */
 #define  PCI_EXP_SLTCAP_PSN0xfff8 /* Physical Slot Number */
+#define PCI_EXP_DEVCAP236  /* Device Capabilities 2 */
+#define  PCI_EXP_DEVCAP2_ARI   0x0020 /* ARI Forwarding Supported */
+#define PCI_EXP_DEVCTL240  /* Device Control 2 */
+#define  PCI_EXP_DEVCTL2_ARI   0x0020 /* Alternative Routing-ID */
+
 #define PCI_EXP_LNKCTL248  /* Link Control 2 */
 /* Single Root I/O Virtualization Registers */
 #define PCI_SRIOV_CAP  0x04/* SR-IOV Capabilities */
 #define PCI_SRIOV_CTRL 0x08/* SR-IOV Control */
 #define  PCI_SRIOV_CTRL_VFE0x01/* VF Enable */
 #define  PCI_SRIOV_CTRL_MSE0x08/* VF Memory Space Enable */
+#define  PCI_SRIOV_CTRL_ARI0x10/* ARI Capable Hierarchy */
 #define PCI_SRIOV_INITIAL_VF   0x0c/* Initial VFs */
 #define PCI_SRIOV_TOTAL_VF 0x0e/* Total VFs */
 #define PCI_SRIOV_NUM_VF   0x10/* Number of VFs */
-- 
2.17.1



[PATCH v4 2/4] pci: layerscape: move pci node search in a common function

2020-09-03 Thread laurentiu . tudor
From: Laurentiu Tudor 

Fix duplication of this code by placing it in a common function.
Furthermore, the resulting function will be re-used in upcoming
patches.

Signed-off-by: Laurentiu Tudor 
---
 drivers/pci/pcie_layerscape_fixup.c | 78 +
 1 file changed, 36 insertions(+), 42 deletions(-)

diff --git a/drivers/pci/pcie_layerscape_fixup.c 
b/drivers/pci/pcie_layerscape_fixup.c
index 7c55e3d249..715c1a7788 100644
--- a/drivers/pci/pcie_layerscape_fixup.c
+++ b/drivers/pci/pcie_layerscape_fixup.c
@@ -22,6 +22,36 @@
 #include "pcie_layerscape.h"
 #include "pcie_layerscape_fixup_common.h"
 
+static int fdt_pcie_get_nodeoffset(void *blob, struct ls_pcie_rc *pcie_rc)
+{
+   int nodeoffset;
+   uint svr;
+   char *compat = NULL;
+
+   /* find pci controller node */
+   nodeoffset = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
+  pcie_rc->dbi_res.start);
+   if (nodeoffset < 0) {
+#ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
+   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A ||
+   svr == SVR_LS2081A || svr == SVR_LS2041A)
+   compat = "fsl,ls2088a-pcie";
+   else
+   compat = CONFIG_FSL_PCIE_COMPAT;
+
+   if (!compat)
+   return nodeoffset;
+   nodeoffset =
+   fdt_node_offset_by_compat_reg(blob, compat,
+ pcie_rc->dbi_res.start);
+#endif
+   }
+
+   return nodeoffset;
+}
+
 #if defined(CONFIG_FSL_LSCH3) || defined(CONFIG_FSL_LSCH2)
 /*
  * Return next available LUT index.
@@ -127,30 +157,11 @@ static void fdt_pcie_set_iommu_map_entry_ls(void *blob,
u32 iommu_map[4];
int nodeoffset;
int lenp;
-   uint svr;
-   char *compat = NULL;
struct ls_pcie *pcie = pcie_rc->pcie;
 
-   /* find pci controller node */
-   nodeoffset = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
-  pcie_rc->dbi_res.start);
-   if (nodeoffset < 0) {
-#ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
-   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
-   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
-   svr == SVR_LS2048A || svr == SVR_LS2044A ||
-   svr == SVR_LS2081A || svr == SVR_LS2041A)
-   compat = "fsl,ls2088a-pcie";
-   else
-   compat = CONFIG_FSL_PCIE_COMPAT;
-
-   if (compat)
-   nodeoffset = fdt_node_offset_by_compat_reg(blob,
-   compat, pcie_rc->dbi_res.start);
-#endif
-   if (nodeoffset < 0)
-   return;
-   }
+   nodeoffset = fdt_pcie_get_nodeoffset(blob, pcie_rc);
+   if (nodeoffset < 0)
+   return;
 
/* get phandle to iommu controller */
prop = fdt_getprop_w(blob, nodeoffset, "iommu-map", );
@@ -232,28 +243,11 @@ static void fdt_fixup_pcie_ls(void *blob)
 static void ft_pcie_rc_fix(void *blob, struct ls_pcie_rc *pcie_rc)
 {
int off;
-   uint svr;
-   char *compat = NULL;
struct ls_pcie *pcie = pcie_rc->pcie;
 
-   off = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
-   pcie_rc->dbi_res.start);
-   if (off < 0) {
-#ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
-   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
-   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
-   svr == SVR_LS2048A || svr == SVR_LS2044A ||
-   svr == SVR_LS2081A || svr == SVR_LS2041A)
-   compat = "fsl,ls2088a-pcie";
-   else
-   compat = CONFIG_FSL_PCIE_COMPAT;
-   if (compat)
-   off = fdt_node_offset_by_compat_reg(blob,
-   compat, pcie_rc->dbi_res.start);
-#endif
-   if (off < 0)
-   return;
-   }
+   off = fdt_pcie_get_nodeoffset(blob, pcie_rc);
+   if (off < 0)
+   return;
 
if (pcie_rc->enabled && pcie->mode == PCI_HEADER_TYPE_BRIDGE)
fdt_set_node_status(blob, off, FDT_STATUS_OKAY, 0);
-- 
2.17.1



[PATCH v4 1/4] pci: layerscape: move per-pci device fdt fixup in a function

2020-09-03 Thread laurentiu . tudor
From: Laurentiu Tudor 

Move the pci device related fdt fixup in a function in order to
re-use it in a following patch. While at it, improve the error
handling.

Signed-off-by: Laurentiu Tudor 
---
 drivers/pci/pcie_layerscape_fixup.c | 60 -
 1 file changed, 34 insertions(+), 26 deletions(-)

diff --git a/drivers/pci/pcie_layerscape_fixup.c 
b/drivers/pci/pcie_layerscape_fixup.c
index 8315b0b590..7c55e3d249 100644
--- a/drivers/pci/pcie_layerscape_fixup.c
+++ b/drivers/pci/pcie_layerscape_fixup.c
@@ -174,12 +174,41 @@ static void fdt_pcie_set_iommu_map_entry_ls(void *blob,
}
 }
 
+static int fdt_fixup_pcie_device_ls(void *blob, pci_dev_t bdf,
+   struct ls_pcie_rc *pcie_rc)
+{
+   int streamid, index;
+
+   streamid = pcie_next_streamid(pcie_rc->stream_id_cur,
+ pcie_rc->pcie->idx);
+   if (streamid < 0) {
+   printf("ERROR: out of stream ids for BDF %d.%d.%d\n",
+  PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
+   return -ENOENT;
+   }
+   pcie_rc->stream_id_cur++;
+
+   index = ls_pcie_next_lut_index(pcie_rc);
+   if (index < 0) {
+   printf("ERROR: out of LUT indexes for BDF %d.%d.%d\n",
+  PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
+   return -ENOENT;
+   }
+
+   /* map PCI b.d.f to streamID in LUT */
+   ls_pcie_lut_set_mapping(pcie_rc, index, bdf >> 8, streamid);
+   /* update msi-map in device tree */
+   fdt_pcie_set_msi_map_entry_ls(blob, pcie_rc, bdf >> 8, streamid);
+   /* update iommu-map in device tree */
+   fdt_pcie_set_iommu_map_entry_ls(blob, pcie_rc, bdf >> 8, streamid);
+
+   return 0;
+}
+
 static void fdt_fixup_pcie_ls(void *blob)
 {
struct udevice *dev, *bus;
struct ls_pcie_rc *pcie_rc;
-   int streamid;
-   int index;
pci_dev_t bdf;
 
/* Scan all known buses */
@@ -190,32 +219,11 @@ static void fdt_fixup_pcie_ls(void *blob)
bus = bus->parent;
pcie_rc = dev_get_priv(bus);
 
-   streamid = pcie_next_streamid(pcie_rc->stream_id_cur,
- pcie_rc->pcie->idx);
-   if (streamid < 0) {
-   debug("ERROR: no stream ids free\n");
-   continue;
-   } else {
-   pcie_rc->stream_id_cur++;
-   }
-
-   index = ls_pcie_next_lut_index(pcie_rc);
-   if (index < 0) {
-   debug("ERROR: no LUT indexes free\n");
-   continue;
-   }
-
/* the DT fixup must be relative to the hose first_busno */
bdf = dm_pci_get_bdf(dev) - PCI_BDF(bus->seq, 0, 0);
-   /* map PCI b.d.f to streamID in LUT */
-   ls_pcie_lut_set_mapping(pcie_rc, index, bdf >> 8,
-   streamid);
-   /* update msi-map in device tree */
-   fdt_pcie_set_msi_map_entry_ls(blob, pcie_rc, bdf >> 8,
- streamid);
-   /* update iommu-map in device tree */
-   fdt_pcie_set_iommu_map_entry_ls(blob, pcie_rc, bdf >> 8,
-   streamid);
+
+   if (fdt_fixup_pcie_device_ls(blob, bdf, pcie_rc) < 0)
+   break;
}
pcie_board_fix_fdt(blob);
 }
-- 
2.17.1



[PATCH v4 0/4] Support for specifying extra IOMMU mappings for PCI

2020-09-03 Thread laurentiu . tudor
From: Laurentiu Tudor 

In the current implementation, u-boot creates iommu mappings only
for PCI devices enumarated at boot time thus does not take into
account more dynamic scenarios such as SR-IOV or PCI hot-plug.
Add support for specifying extra IOMMU mappings for PCI
controllers through a special env var called "pci_iommu_extra" or
through a device tree property named "pci-iommu-extra" placed in
the node describing the PCI controller. More detailed information
can be found in the final patch.

Changes in v4:
 - rebased
 - fixed compilation issue on ls1021a based boards

Changes in v3:
 - rebased
 - trimmed commit message of the last patch
 - minor adjustments to the readme file

Changes in v2:
 - add ARI support and use it by default
 - option to disable ARI
 - fixes in BDF calculation
 - reorganized code a bit
 - added more comments

Laurentiu Tudor (4):
  pci: layerscape: move per-pci device fdt fixup in a function
  pci: layerscape: move pci node search in a common function
  pci: add a few ARI related defines
  pci: layerscape: add a way of specifying additional iommu mappings

 .../fsl-layerscape/doc/README.pci_iommu_extra |  67 +++
 drivers/pci/Kconfig   |  12 +
 drivers/pci/pcie_layerscape_fixup.c   | 460 +++---
 include/pci.h |   6 +
 4 files changed, 480 insertions(+), 65 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra

-- 
2.17.1



Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Edgar E. Iglesias
On Thu, Sep 03, 2020 at 02:52:39PM +0100, André Przywara wrote:
> On 03/09/2020 14:41, Michal Simek wrote:
> > 
> > 
> > On 02. 09. 20 20:59, André Przywara wrote:
> >> On 02/09/2020 16:25, Edgar E. Iglesias wrote:
> >>> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
>  On 02/09/2020 15:53, Edgar E. Iglesias wrote:
> > On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
> >> On 02/09/2020 12:15, Michal Simek wrote:
> 
>  Hi,
> 
> >>
> >>> From: "Edgar E. Iglesias" 
> >>>
> >>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
> >>> compilation error is shown:
> >>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): 
> >>> relocation
> >>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol 
> >>> `__rel_dyn_end'
> >>> defined in .bss_start section in u-boot.
> >>>
> >>> It is caused by adr instruction which permits the calculation of any 
> >>> byte
> >>> address within +- 1MB of the current PC.
> >>> Because U-Boot is bigger then 1MB calculation is failing.
> >>>
> >>> The patch is using adrp/add instructions where adrp shifts a signed, 
> >>> 21-bit
> >>> immediate left by 12 bits (4k page), adds it to the value of the 
> >>> program
> >>> counter with the bottom 12 bits cleared to zero. Then add instruction
> >>> provides the lower 12 bits which is offset within 4k page.
> >>> These two instructions together compose full 32bit offset which 
> >>> should be
> >>> more then enough to cover the whole u-boot size.
> >>>
> >>> Signed-off-by: Edgar E. Iglesias 
> >>> Signed-off-by: Michal Simek 
> >>
> >> It's a bit scary that you need more than 1MB, but indeed what you do
> >> below is the canonical pattern to get the full range of PC relative
> >> addressing (this is used heavily in Trusted Firmware, for instance).
> >>
> >> The only thing to keep in mind is that this assumes that the load
> >> address of the binary is 4K aligned, so that the low 12 bits of the
> >> symbol stay the same. I wonder if we should enforce this somehow? But
> >> the load address is not controlled by the build process (the whole
> >> purpose of PIE), so that's not doable just in the build system?
> >
> > There shouldn't be any need for 4K alignment. Could you elaborate on
> > why you think there is?
> 
>  That seems to be slightly tricky, and I tried to get some confirmation,
>  but here goes my reasoning. Maybe you can confirm this:
> 
>  - adrp takes the relative offset, but only of the upper 20 bits (because
>  that's all we can encode). It clears the lower 12 bits of the register.
>  - the "add" is not PC relative anymore, so it just takes the lower 12
>  bits of the "absolute" linker symbol.
> >>>
> >>> I was under the impression that this would use a PC-relative lower 12bit
> >>> relocation but you are correct. I dissasembled the result:
> >>>
> >>>   40:   9142add x2, x2, #0x0
> >>> 40: R_AARCH64_ADD_ABS_LO12_NC   __rel_dyn_start
> >>>
> >>>
> >>>
> >>>
> >>>
>  So this assumes that the lower 12 bits of the actual address in memory
>  and the lower 12 bits of the linker's view match.
>  An example:
>  00024: adrp x0, SYMBOL
>  00028: add  x0, x0, :lo12:SYMBOL
> 
>  SYMBOL:
>  42058: ...
> 
>  The toolchain will generate:
>   adrp x0, #0x42; add x0, x0, #0x058
> 
>  Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at
>  0x80042858.
>  The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000.
>  The add will just add 0x58, so you end up with x0 being 0x80042058,
>  which is not the right address.
> 
>  Does this make sense?
> >>>
> >>>
> >>> Yes, it makes sense.
> >>>
> 
> > Perhaps the commit message is a little confusing. The toolchain will
> > compute the pc-relative offset from this particular location to the
> > symbol and apply the relocations accordingly.
> 
>  Yes, but the PC relative offset applies only to the upper 20 bits,
>  because it's only adrp that has PC relative semantics.
> 
> 
> >>
> >> Shall we at least document this? I guess typical load address are
> >> actually quite well aligned, so it might not be an issue in practice.
> >>
> >>>
> >>> Yes, probably worth documenting and perhaps an early bail-out if it's not
> >>> the case...
> >>
> >> Documenting sounds good, Kconfig might be a good place, as Michal 
> >> suggested.
> >>
> >> Bail out: I thought about that, it's very easy to detect at runtime, but
> >> what then? This is really early, so you could just enter a WFI loop, and
> >> hope for someone to connect the dots?
> >> Or can you think of any other way of communicating with the user?
> > 
> > yes it is very early. It is 

Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread André Przywara
On 03/09/2020 14:41, Michal Simek wrote:
> 
> 
> On 02. 09. 20 20:59, André Przywara wrote:
>> On 02/09/2020 16:25, Edgar E. Iglesias wrote:
>>> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
 On 02/09/2020 15:53, Edgar E. Iglesias wrote:
> On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
>> On 02/09/2020 12:15, Michal Simek wrote:

 Hi,

>>
>>> From: "Edgar E. Iglesias" 
>>>
>>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>>> compilation error is shown:
>>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>>> defined in .bss_start section in u-boot.
>>>
>>> It is caused by adr instruction which permits the calculation of any 
>>> byte
>>> address within +- 1MB of the current PC.
>>> Because U-Boot is bigger then 1MB calculation is failing.
>>>
>>> The patch is using adrp/add instructions where adrp shifts a signed, 
>>> 21-bit
>>> immediate left by 12 bits (4k page), adds it to the value of the program
>>> counter with the bottom 12 bits cleared to zero. Then add instruction
>>> provides the lower 12 bits which is offset within 4k page.
>>> These two instructions together compose full 32bit offset which should 
>>> be
>>> more then enough to cover the whole u-boot size.
>>>
>>> Signed-off-by: Edgar E. Iglesias 
>>> Signed-off-by: Michal Simek 
>>
>> It's a bit scary that you need more than 1MB, but indeed what you do
>> below is the canonical pattern to get the full range of PC relative
>> addressing (this is used heavily in Trusted Firmware, for instance).
>>
>> The only thing to keep in mind is that this assumes that the load
>> address of the binary is 4K aligned, so that the low 12 bits of the
>> symbol stay the same. I wonder if we should enforce this somehow? But
>> the load address is not controlled by the build process (the whole
>> purpose of PIE), so that's not doable just in the build system?
>
> There shouldn't be any need for 4K alignment. Could you elaborate on
> why you think there is?

 That seems to be slightly tricky, and I tried to get some confirmation,
 but here goes my reasoning. Maybe you can confirm this:

 - adrp takes the relative offset, but only of the upper 20 bits (because
 that's all we can encode). It clears the lower 12 bits of the register.
 - the "add" is not PC relative anymore, so it just takes the lower 12
 bits of the "absolute" linker symbol.
>>>
>>> I was under the impression that this would use a PC-relative lower 12bit
>>> relocation but you are correct. I dissasembled the result:
>>>
>>>   40:   9142add x2, x2, #0x0
>>> 40: R_AARCH64_ADD_ABS_LO12_NC   __rel_dyn_start
>>>
>>>
>>>
>>>
>>>
 So this assumes that the lower 12 bits of the actual address in memory
 and the lower 12 bits of the linker's view match.
 An example:
 00024: adrp x0, SYMBOL
 00028: add  x0, x0, :lo12:SYMBOL

 SYMBOL:
 42058: ...

 The toolchain will generate:
adrp x0, #0x42; add x0, x0, #0x058

 Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at
 0x80042858.
 The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000.
 The add will just add 0x58, so you end up with x0 being 0x80042058,
 which is not the right address.

 Does this make sense?
>>>
>>>
>>> Yes, it makes sense.
>>>

> Perhaps the commit message is a little confusing. The toolchain will
> compute the pc-relative offset from this particular location to the
> symbol and apply the relocations accordingly.

 Yes, but the PC relative offset applies only to the upper 20 bits,
 because it's only adrp that has PC relative semantics.


>>
>> Shall we at least document this? I guess typical load address are
>> actually quite well aligned, so it might not be an issue in practice.
>>
>>>
>>> Yes, probably worth documenting and perhaps an early bail-out if it's not
>>> the case...
>>
>> Documenting sounds good, Kconfig might be a good place, as Michal suggested.
>>
>> Bail out: I thought about that, it's very easy to detect at runtime, but
>> what then? This is really early, so you could just enter a WFI loop, and
>> hope for someone to connect the dots?
>> Or can you think of any other way of communicating with the user?
> 
> yes it is very early. It is the first real task what run after reset.
> I am fine with detecting it to make sure that we won't have
> unpredictable behavior later.
> What detection code do you have in mind?

Just "adr"ing the beginning of the image (linker address 0), and
checking for all 12 LSBs to be 0. The best I thought of would be a WFI
loop if not. That 

Re: U-Boot fails dfu on edison

2020-09-03 Thread Andy Shevchenko
On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
 wrote:
> On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:

...

> Hmm... Have you read this [1]? It may give some hints I think.
>
> [1]: https://edison-fw.github.io/edison-wiki/u-boot-update (look into 
> known-bugs section)
>
> > Any ideas please?
>
> See above.

Just in case my script [2] to prepare a U-Boot image file suitable for xFSTK.

[2]: https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f

-- 
With Best Regards,
Andy Shevchenko


Re: [PULL] u-boot-usb/master

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 03:35:30PM +0200, Marek Vasut wrote:

> On 9/3/20 3:03 PM, Tom Rini wrote:
> > On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:
> > 
> >> Mostly DFU fixes and r8152 fixes below:
> >>
> >> The following changes since commit 
> >> 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
> >>
> >>   MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
> >> 17:11:24 -0400)
> >>
> >> are available in the Git repository at:
> >>
> >>   git://git.denx.de/u-boot-usb.git master
> >>
> >> for you to fetch changes up to 293a6dfeb96129abebf1ad927fa9aedf03a66d34:
> >>
> >>   fastboot: getvar: fix partition-size return value (2020-09-01 14:47:43
> >> +0200)
> >>
> >> 
> >> Filip Brozovic (1):
> >>   fastboot: Support defining raw partitions without a partition table
> >>
> >> Frank Li (1):
> >>   sdp: call board_usb_init at spl_sdp_load_image
> >>
> >> Gary Bisson (1):
> >>   fastboot: getvar: fix partition-size return value
> >>
> >> Hayes Wang (4):
> >>   eth/r8152: reset bmu after disabling Tx/Rx
> >>   eth/r8152: reset PHY after setting it
> >>   eth/r8152: modify rtl_clear_bp function
> >>   eth/r8152: support RTL8153B/RTL8154B
> >>
> >> Heinrich Schuchardt (4):
> >>   dfu: fix typo parameteres
> >>   dfu: DFU_MTD depends on CMD_MTDPARTS
> >>   configs: qemu: enable dfu testing
> >>   dfu: fix dfu tftp on sandbox
> >>
> >> Jassi Brar (1):
> >>   usb: max3420: add the gadget driver
> >>
> >> Peng Fan (2):
> >>   f_sdp: Support searching and loading FIT or container image
> >>   spl: add g_dnl_get_board_bcd_device_number
> >>
> >> Roman Kovalivskyi (3):
> >>   fastboot: Extend fastboot_set_reboot_flag with reboot reason
> >>   fastboot: Add support for 'reboot fastboot' command
> >>   fastboot: Add default fastboot_set_reboot_flag implementation
> >>
> >> Sherry Sun (2):
> >>   f_sdp: Add EP1_OUT as default data receive pipe in sdp
> >>   f_sdp: Change bInterval of interrupt endpoint to 3
> >>
> >> Ye Li (4):
> >>   usb: gadget: Fix controller index in UMS
> >>   usb: ci_udc: Add function to remove usb device
> >>   f_sdp: Add high speed endpoint descriptor
> >>   f_sdp: Fix wrong usb request size
> >>
> >> yurii.pidhornyi (1):
> >>   fastboot: Fix fastboot reboot fail by changing functions order
> >>
> >>  arch/arm/mach-imx/spl.c |   6 +
> >>  arch/arm/mach-meson/board-common.c  |   6 +-
> >>  arch/arm/mach-rockchip/board.c  |   6 +-
> >>  board/amazon/kc1/kc1.c  |   6 +-
> >>  board/lg/sniper/sniper.c|   6 +-
> >>  board/ti/am57xx/board.c |   6 +-
> >>  board/ti/dra7xx/evm.c   |   6 +-
> >>  cmd/usb_mass_storage.c  |   2 +-
> >>  common/spl/spl_sdp.c|   2 +
> >>  common/update.c |   6 +-
> >>  configs/qemu_arm64_defconfig|   9 +
> >>  configs/qemu_arm_defconfig  |   9 +
> >>  doc/android/fastboot.rst|  19 +++
> >>  drivers/dfu/Kconfig |   1 +
> >>  drivers/dfu/dfu_ram.c   |   7 +-
> >>  drivers/fastboot/Kconfig|  12 ++
> >>  drivers/fastboot/Makefile   |   1 +
> >>  drivers/fastboot/fb_bcb_impl.c  |  43 +
> >>  drivers/fastboot/fb_command.c   |  40 -
> >>  drivers/fastboot/fb_common.c|   2 +-
> >>  drivers/fastboot/fb_getvar.c|   4 +-
> >>  drivers/fastboot/fb_mmc.c   |  75 -
> >>  drivers/usb/eth/r8152.c | 223 -
> >>  drivers/usb/eth/r8152.h |  59 +--
> >>  drivers/usb/eth/r8152_fw.c  | 228 +++---
> >>  drivers/usb/gadget/Kconfig  |   6 +
> >>  drivers/usb/gadget/Makefile |   1 +
> >>  drivers/usb/gadget/ci_udc.c |   7 +
> >>  drivers/usb/gadget/f_fastboot.c |   6 +-
> >>  drivers/usb/gadget/f_mass_storage.c |   6 +-
> >>  drivers/usb/gadget/f_sdp.c  | 219 +
> >>  drivers/usb/gadget/gadget_chips.h   |   8 +
> >>  drivers/usb/gadget/max3420_udc.c| 875
> >> +
> >>  drivers/usb/host/usb-uclass.c   |  18 ++
> >>  include/dfu.h   |   2 +-
> >>  include/fastboot.h  |  23 ++-
> >>  include/usb.h   |   9 +
> >>  include/usb_mass_storage.h  |   2 +-
> >>  net/fastboot.c  |   2 +
> >>  39 files changed, 1867 insertions(+), 101 deletions(-)
> >>  create mode 100644 drivers/fastboot/fb_bcb_impl.c
> >>  create mode 100644 drivers/usb/gadget/max3420_udc.c
> > 
> > This feels like a lot.  Is it really a good time to take these for
> > v2020.10 or should I put them in -next, next week when it opens?
> 
> I pushed Lukasz to include only fixes, and I trust him that's what's in
> there. I 

Re: [PATCH v2 1/3] spl: fit: Minimally parse OS properties with FIT_IMAGE_TINY

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 01:08:13AM -0500, Samuel Holland wrote:

> Some boards, specifically 64-bit Allwinner boards (sun50i), are
> extremely limited on SPL size. One strategy that was used to make space
> was to remove the FIT "os" property parsing code, because it uses a
> rather large lookup table.
> 
> However, this forces the legacy FIT parsing code path, which requires
> the "firmware" entry in the FIT to reference the U-Boot binary, even if
> U-Boot is not the next binary in the boot sequence (for example, on
> sun50i boards, ATF is run first).
> 
> This prevents the same FIT image from being used with a SPL with
> CONFIG_SPL_FIT_IMAGE_TINY=n and CONFIG_SPL_ATF=y, because the boot
> method selection code looks at `spl_image.os`, which is only set from
> the "firmware" entry's "os" property.
> 
> To be able to use CONFIG_SPL_ATF=y, the "firmware" entry in the FIT
> must be ATF, and U-Boot must be a loadable. For this to work, we need to
> parse the "os" property just enough to tell U-Boot from other images, so
> we can find it in the loadables list to append the FDT, and so we don't
> try to append the FDT to ATF (which could clobber adjacent firmware).
> 
> So add the minimal code necessary to distinguish U-Boot/non-U-Boot
> loadables with CONFIG_SPL_FIT_IMAGE_TINY=y. This adds about 300 bytes,
> much less than the 7400 bytes added by CONFIG_SPL_FIT_IMAGE_TINY=n.
> 
> Acked-by: Patrick Wildt 
> Signed-off-by: Samuel Holland 

(No need to repost just to collect tags, patchwork does that for us
here, thanks).

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Michal Simek



On 02. 09. 20 20:59, André Przywara wrote:
> On 02/09/2020 16:25, Edgar E. Iglesias wrote:
>> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
>>> On 02/09/2020 15:53, Edgar E. Iglesias wrote:
 On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
> On 02/09/2020 12:15, Michal Simek wrote:
>>>
>>> Hi,
>>>
>
>> From: "Edgar E. Iglesias" 
>>
>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>> compilation error is shown:
>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>> defined in .bss_start section in u-boot.
>>
>> It is caused by adr instruction which permits the calculation of any byte
>> address within +- 1MB of the current PC.
>> Because U-Boot is bigger then 1MB calculation is failing.
>>
>> The patch is using adrp/add instructions where adrp shifts a signed, 
>> 21-bit
>> immediate left by 12 bits (4k page), adds it to the value of the program
>> counter with the bottom 12 bits cleared to zero. Then add instruction
>> provides the lower 12 bits which is offset within 4k page.
>> These two instructions together compose full 32bit offset which should be
>> more then enough to cover the whole u-boot size.
>>
>> Signed-off-by: Edgar E. Iglesias 
>> Signed-off-by: Michal Simek 
>
> It's a bit scary that you need more than 1MB, but indeed what you do
> below is the canonical pattern to get the full range of PC relative
> addressing (this is used heavily in Trusted Firmware, for instance).
>
> The only thing to keep in mind is that this assumes that the load
> address of the binary is 4K aligned, so that the low 12 bits of the
> symbol stay the same. I wonder if we should enforce this somehow? But
> the load address is not controlled by the build process (the whole
> purpose of PIE), so that's not doable just in the build system?

 There shouldn't be any need for 4K alignment. Could you elaborate on
 why you think there is?
>>>
>>> That seems to be slightly tricky, and I tried to get some confirmation,
>>> but here goes my reasoning. Maybe you can confirm this:
>>>
>>> - adrp takes the relative offset, but only of the upper 20 bits (because
>>> that's all we can encode). It clears the lower 12 bits of the register.
>>> - the "add" is not PC relative anymore, so it just takes the lower 12
>>> bits of the "absolute" linker symbol.
>>
>> I was under the impression that this would use a PC-relative lower 12bit
>> relocation but you are correct. I dissasembled the result:
>>
>>   40:   9142add x2, x2, #0x0
>> 40: R_AARCH64_ADD_ABS_LO12_NC   __rel_dyn_start
>>
>>
>>
>>
>>
>>> So this assumes that the lower 12 bits of the actual address in memory
>>> and the lower 12 bits of the linker's view match.
>>> An example:
>>> 00024: adrp x0, SYMBOL
>>> 00028: add  x0, x0, :lo12:SYMBOL
>>>
>>> SYMBOL:
>>> 42058: ...
>>>
>>> The toolchain will generate:
>>> adrp x0, #0x42; add x0, x0, #0x058
>>>
>>> Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at
>>> 0x80042858.
>>> The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000.
>>> The add will just add 0x58, so you end up with x0 being 0x80042058,
>>> which is not the right address.
>>>
>>> Does this make sense?
>>
>>
>> Yes, it makes sense.
>>
>>>
 Perhaps the commit message is a little confusing. The toolchain will
 compute the pc-relative offset from this particular location to the
 symbol and apply the relocations accordingly.
>>>
>>> Yes, but the PC relative offset applies only to the upper 20 bits,
>>> because it's only adrp that has PC relative semantics.
>>>
>>>
>
> Shall we at least document this? I guess typical load address are
> actually quite well aligned, so it might not be an issue in practice.
>
>>
>> Yes, probably worth documenting and perhaps an early bail-out if it's not
>> the case...
> 
> Documenting sounds good, Kconfig might be a good place, as Michal suggested.
> 
> Bail out: I thought about that, it's very easy to detect at runtime, but
> what then? This is really early, so you could just enter a WFI loop, and
> hope for someone to connect the dots?
> Or can you think of any other way of communicating with the user?

yes it is very early. It is the first real task what run after reset.
I am fine with detecting it to make sure that we won't have
unpredictable behavior later.
What detection code do you have in mind?
Don't we even have this 4k alignment in place already?

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx 

Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread André Przywara
On 03/09/2020 14:35, Michal Simek wrote:
> 
> 
> On 02. 09. 20 18:34, Stephen Warren wrote:
>> On 9/2/20 5:15 AM, Michal Simek wrote:
>>> From: "Edgar E. Iglesias" 
>>>
>>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>>> compilation error is shown:
>>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>>> defined in .bss_start section in u-boot.
>>>
>>> It is caused by adr instruction which permits the calculation of any byte
>>> address within +- 1MB of the current PC.
>>> Because U-Boot is bigger then 1MB calculation is failing.
>>>
>>> The patch is using adrp/add instructions where adrp shifts a signed, 21-bit
>>> immediate left by 12 bits (4k page), adds it to the value of the program
>>> counter with the bottom 12 bits cleared to zero. Then add instruction
>>> provides the lower 12 bits which is offset within 4k page.
>>> These two instructions together compose full 32bit offset which should be
>>> more then enough to cover the whole u-boot size.
>>
>>> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
>>
>>> @@ -67,8 +67,10 @@ pie_fixup:
>>> adr x0, _start  /* x0 <- Runtime value of _start */
>>> ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
>>> sub x9, x0, x1  /* x9 <- Run-vs-link offset */
>>> -   adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>>> -   adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>>> +   adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>>> +   add x2, x2, #:lo12:__rel_dyn_start
>>> +   adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>>> +   add x3, x3, #:lo12:__rel_dyn_end
>>>  pie_fix_loop:
>>> ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, fixup) */
>>> ldr x4, [x2], #8/* x4 <- addend */
>>
>> There are likely a bunch of other places in the code that need updating
>> too; take a look at commit 49e93875a62f "arm64: support running at addr
>> other than linked to" (which introduced the code above) to find other
>> places with similar instruction sequences that almost certainly need
>> updating.
>>
> 
> I didn't hit any issue to have a need to update them. Definitely worth
> to check that locations too.

So I thought the same, so I checked at least this file. And while there
are other "adr" instructions, they only go to nearby labels, so don't
need to be pumped up.
But I will try to grep for more cases as well.

Cheers,
Andre


Re: U-Boot fails dfu on edison

2020-09-03 Thread Andy Shevchenko
On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:
> Hi,
> 
> I'd like to get edison running in my lab but it has resisted two
> attempts so far.
> 
> My latest problem is that when I try the latest U-Boot, I get:
> 
> U-Boot 2020.10-rc3-00012-g9f04a634ef3 (Sep 03 2020 - 07:06:30 -0600)

Do you have clean repo?

Can't reproduce neither with my personal branch nor with vanilla -rc3:


U-Boot 2020.10-rc3 (Sep 03 2020 - 16:33:27 +0300)

CPU:   Intel(R) Atom(TM) CPU  U1000  @  500MHz
DRAM:  980.6 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
Loading Environment from MMC... OK
In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
=> 
=> run do_force_flash_os
Saving Environment to MMC... Writing to redundant MMC(0)... OK



Maybe something wrong with the environment?

...

> Target:blank
> Partitioning already done...
> Flashing already done...
> Memory layout (mmc) not supported!
> DFU entities configuration failed!
> (partition table does not match dfu_alt_info?)

Hmm... Have you read this [1]? It may give some hints I think.

[1]: https://edison-fw.github.io/edison-wiki/u-boot-update (look into 
known-bugs section)

> Any ideas please?

See above.

-- 
With Best Regards,
Andy Shevchenko




Re: [PULL] u-boot-usb/master

2020-09-03 Thread Marek Vasut
On 9/3/20 3:03 PM, Tom Rini wrote:
> On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:
> 
>> Mostly DFU fixes and r8152 fixes below:
>>
>> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
>>
>>   MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
>> 17:11:24 -0400)
>>
>> are available in the Git repository at:
>>
>>   git://git.denx.de/u-boot-usb.git master
>>
>> for you to fetch changes up to 293a6dfeb96129abebf1ad927fa9aedf03a66d34:
>>
>>   fastboot: getvar: fix partition-size return value (2020-09-01 14:47:43
>> +0200)
>>
>> 
>> Filip Brozovic (1):
>>   fastboot: Support defining raw partitions without a partition table
>>
>> Frank Li (1):
>>   sdp: call board_usb_init at spl_sdp_load_image
>>
>> Gary Bisson (1):
>>   fastboot: getvar: fix partition-size return value
>>
>> Hayes Wang (4):
>>   eth/r8152: reset bmu after disabling Tx/Rx
>>   eth/r8152: reset PHY after setting it
>>   eth/r8152: modify rtl_clear_bp function
>>   eth/r8152: support RTL8153B/RTL8154B
>>
>> Heinrich Schuchardt (4):
>>   dfu: fix typo parameteres
>>   dfu: DFU_MTD depends on CMD_MTDPARTS
>>   configs: qemu: enable dfu testing
>>   dfu: fix dfu tftp on sandbox
>>
>> Jassi Brar (1):
>>   usb: max3420: add the gadget driver
>>
>> Peng Fan (2):
>>   f_sdp: Support searching and loading FIT or container image
>>   spl: add g_dnl_get_board_bcd_device_number
>>
>> Roman Kovalivskyi (3):
>>   fastboot: Extend fastboot_set_reboot_flag with reboot reason
>>   fastboot: Add support for 'reboot fastboot' command
>>   fastboot: Add default fastboot_set_reboot_flag implementation
>>
>> Sherry Sun (2):
>>   f_sdp: Add EP1_OUT as default data receive pipe in sdp
>>   f_sdp: Change bInterval of interrupt endpoint to 3
>>
>> Ye Li (4):
>>   usb: gadget: Fix controller index in UMS
>>   usb: ci_udc: Add function to remove usb device
>>   f_sdp: Add high speed endpoint descriptor
>>   f_sdp: Fix wrong usb request size
>>
>> yurii.pidhornyi (1):
>>   fastboot: Fix fastboot reboot fail by changing functions order
>>
>>  arch/arm/mach-imx/spl.c |   6 +
>>  arch/arm/mach-meson/board-common.c  |   6 +-
>>  arch/arm/mach-rockchip/board.c  |   6 +-
>>  board/amazon/kc1/kc1.c  |   6 +-
>>  board/lg/sniper/sniper.c|   6 +-
>>  board/ti/am57xx/board.c |   6 +-
>>  board/ti/dra7xx/evm.c   |   6 +-
>>  cmd/usb_mass_storage.c  |   2 +-
>>  common/spl/spl_sdp.c|   2 +
>>  common/update.c |   6 +-
>>  configs/qemu_arm64_defconfig|   9 +
>>  configs/qemu_arm_defconfig  |   9 +
>>  doc/android/fastboot.rst|  19 +++
>>  drivers/dfu/Kconfig |   1 +
>>  drivers/dfu/dfu_ram.c   |   7 +-
>>  drivers/fastboot/Kconfig|  12 ++
>>  drivers/fastboot/Makefile   |   1 +
>>  drivers/fastboot/fb_bcb_impl.c  |  43 +
>>  drivers/fastboot/fb_command.c   |  40 -
>>  drivers/fastboot/fb_common.c|   2 +-
>>  drivers/fastboot/fb_getvar.c|   4 +-
>>  drivers/fastboot/fb_mmc.c   |  75 -
>>  drivers/usb/eth/r8152.c | 223 -
>>  drivers/usb/eth/r8152.h |  59 +--
>>  drivers/usb/eth/r8152_fw.c  | 228 +++---
>>  drivers/usb/gadget/Kconfig  |   6 +
>>  drivers/usb/gadget/Makefile |   1 +
>>  drivers/usb/gadget/ci_udc.c |   7 +
>>  drivers/usb/gadget/f_fastboot.c |   6 +-
>>  drivers/usb/gadget/f_mass_storage.c |   6 +-
>>  drivers/usb/gadget/f_sdp.c  | 219 +
>>  drivers/usb/gadget/gadget_chips.h   |   8 +
>>  drivers/usb/gadget/max3420_udc.c| 875
>> +
>>  drivers/usb/host/usb-uclass.c   |  18 ++
>>  include/dfu.h   |   2 +-
>>  include/fastboot.h  |  23 ++-
>>  include/usb.h   |   9 +
>>  include/usb_mass_storage.h  |   2 +-
>>  net/fastboot.c  |   2 +
>>  39 files changed, 1867 insertions(+), 101 deletions(-)
>>  create mode 100644 drivers/fastboot/fb_bcb_impl.c
>>  create mode 100644 drivers/usb/gadget/max3420_udc.c
> 
> This feels like a lot.  Is it really a good time to take these for
> v2020.10 or should I put them in -next, next week when it opens?

I pushed Lukasz to include only fixes, and I trust him that's what's in
there. I also had a look myself, and yeah, it's fixes. Except for the
max3420, which was on the list for a long time and is isolated, so
that's OK.


Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

2020-09-03 Thread Michal Simek



On 02. 09. 20 18:34, Stephen Warren wrote:
> On 9/2/20 5:15 AM, Michal Simek wrote:
>> From: "Edgar E. Iglesias" 
>>
>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>> compilation error is shown:
>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>> defined in .bss_start section in u-boot.
>>
>> It is caused by adr instruction which permits the calculation of any byte
>> address within +- 1MB of the current PC.
>> Because U-Boot is bigger then 1MB calculation is failing.
>>
>> The patch is using adrp/add instructions where adrp shifts a signed, 21-bit
>> immediate left by 12 bits (4k page), adds it to the value of the program
>> counter with the bottom 12 bits cleared to zero. Then add instruction
>> provides the lower 12 bits which is offset within 4k page.
>> These two instructions together compose full 32bit offset which should be
>> more then enough to cover the whole u-boot size.
> 
>> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> 
>> @@ -67,8 +67,10 @@ pie_fixup:
>>  adr x0, _start  /* x0 <- Runtime value of _start */
>>  ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
>>  sub x9, x0, x1  /* x9 <- Run-vs-link offset */
>> -adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>> -adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>> +adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>> +add x2, x2, #:lo12:__rel_dyn_start
>> +adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>> +add x3, x3, #:lo12:__rel_dyn_end
>>  pie_fix_loop:
>>  ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, fixup) */
>>  ldr x4, [x2], #8/* x4 <- addend */
> 
> There are likely a bunch of other places in the code that need updating
> too; take a look at commit 49e93875a62f "arm64: support running at addr
> other than linked to" (which introduced the code above) to find other
> places with similar instruction sequences that almost certainly need
> updating.
> 

I didn't hit any issue to have a need to update them. Definitely worth
to check that locations too.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs



Re: [PATCH v3 00/12] binman: Add support for generating more complex FITs

2020-09-03 Thread Michal Simek
Hi Simon,

On 02. 09. 20 19:07, Simon Glass wrote:
> Hi Michal,
> 
> On Wed, 2 Sep 2020 at 04:27, Michal Simek  wrote:
>>
>> Hi Simon,
>>
>> On 01. 09. 20 13:13, Simon Glass wrote:
>>> This series allows binman to generate FITs that include multiple DTB
>>> images and the configuration to use them.
>>>
>>> It is then possible to remove the sunxi FIT generator script, so this
>>> series handles that also.
>>>
>>> With this, sunxi is fully converted to use binman.
>>>
>>> Note: This series is available at u-boot-dm/binman-working and is based
>>> on u-boot-dm/testing
>>
>> I continue on testing this series on ZynqMP and reach one issue. One of
>> our usecase is to put u-boot on memory above 32bit address space.
>> To be accurate to this memory range.
>> reg = <0x8 0x 0x0 0x8000>;
>>
>> One way to get there is to setup TEXT_BASE to for example 0x80800.
>> Then u-boot.itb fragment for binmap looks like this.
>>
>> u-boot-itb {
>> filename = "u-boot.itb";
>> fit {
>> description = "FIT image with ATF support";
>> fit,fdt-list = "of-list";
>> #address-cells = <2>;
>>
>> images {
>> uboot {
>> description = "U-Boot (64-bit)";
>> type = "firmware";
>> os = "u-boot";
>> arch = "arm64";
>> compression = "none";
>> load = <8 0x800>;
>> entry = <8 0x800>;
>> u-boot-nodtb {
>> };
>> };
>> ...
>> The key properties are load/entry. In example above I have address-cells
>> = 2 and entries written by hand and it works fine.
>> But I want to use CONFIG_SYS_TEXT_BASE there which is already in 64bit
>> format.
>>
>> When this is used I get
>> Error: arch/arm/dts/zynqmp-u-boot.dtsi:31.14-25 Value out of range for
>> 32-bit array element
>> Error: arch/arm/dts/zynqmp-u-boot.dtsi:32.15-26 Value out of range for
>> 32-bit array element
>>
>> Which is understandable but my question is how to handle 64bit addresses
>> which are properly filled via Kconfig?
> 
> If I understand the problem correctly, you can add 64-bit values like this:
> 
> load = /bits/ 64 ;

ok. This works - thanks for that.

I have sent 2 patches for adding 64bit support to use this feature.

Thanks,
Michal






U-Boot fails dfu on edison

2020-09-03 Thread Simon Glass
Hi,

I'd like to get edison running in my lab but it has resisted two
attempts so far.

My latest problem is that when I try the latest U-Boot, I get:

U-Boot 2020.10-rc3-00012-g9f04a634ef3 (Sep 03 2020 - 07:06:30 -0600)

CPU:   Genuine Intel(R) CPU   4000  @  500MHz
DRAM:  980.6 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
Loading Environment from MMC... OK
In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Target:blank
Partitioning already done...
Flashing already done...
Memory layout (mmc) not supported!
DFU entities configuration failed!
(partition table does not match dfu_alt_info?)
dfu - Device Firmware Upgrade

Usage:
dfu  [ ] [] [list]
  - device firmware upgrade via 
on device , attached to interface

[] - specify inactivity timeout in seconds
[list] - list available alt settings

I tried resetting the environment, but then it seems to just clear the
environment.

=> env default -a
## Resetting to default environment
## Error: Can't force access to "bootdelay"
## Error: Can't force access to "baudrate"

Then I rebooted and tried the instructions in edison.rst :

 run do_force_flash_os
Saving Environment to MMC... Writing to MMC(0)... OK
Memory layout (mmc) not supported!
DFU entities configuration failed!
(partition table does not match dfu_alt_info?)
dfu - Device Firmware Upgrade

Usage:
dfu  [ ] [] [list]
  - device firmware upgrade via 
on device , attached to interface

[] - specify inactivity timeout in seconds
[list] - list available alt settings


Any ideas please?

Regards,
Simon


Re: [PULL] u-boot-usb/master

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:

> Mostly DFU fixes and r8152 fixes below:
> 
> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
> 
>   MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
> 17:11:24 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 293a6dfeb96129abebf1ad927fa9aedf03a66d34:
> 
>   fastboot: getvar: fix partition-size return value (2020-09-01 14:47:43
> +0200)
> 
> 
> Filip Brozovic (1):
>   fastboot: Support defining raw partitions without a partition table
> 
> Frank Li (1):
>   sdp: call board_usb_init at spl_sdp_load_image
> 
> Gary Bisson (1):
>   fastboot: getvar: fix partition-size return value
> 
> Hayes Wang (4):
>   eth/r8152: reset bmu after disabling Tx/Rx
>   eth/r8152: reset PHY after setting it
>   eth/r8152: modify rtl_clear_bp function
>   eth/r8152: support RTL8153B/RTL8154B
> 
> Heinrich Schuchardt (4):
>   dfu: fix typo parameteres
>   dfu: DFU_MTD depends on CMD_MTDPARTS
>   configs: qemu: enable dfu testing
>   dfu: fix dfu tftp on sandbox
> 
> Jassi Brar (1):
>   usb: max3420: add the gadget driver
> 
> Peng Fan (2):
>   f_sdp: Support searching and loading FIT or container image
>   spl: add g_dnl_get_board_bcd_device_number
> 
> Roman Kovalivskyi (3):
>   fastboot: Extend fastboot_set_reboot_flag with reboot reason
>   fastboot: Add support for 'reboot fastboot' command
>   fastboot: Add default fastboot_set_reboot_flag implementation
> 
> Sherry Sun (2):
>   f_sdp: Add EP1_OUT as default data receive pipe in sdp
>   f_sdp: Change bInterval of interrupt endpoint to 3
> 
> Ye Li (4):
>   usb: gadget: Fix controller index in UMS
>   usb: ci_udc: Add function to remove usb device
>   f_sdp: Add high speed endpoint descriptor
>   f_sdp: Fix wrong usb request size
> 
> yurii.pidhornyi (1):
>   fastboot: Fix fastboot reboot fail by changing functions order
> 
>  arch/arm/mach-imx/spl.c |   6 +
>  arch/arm/mach-meson/board-common.c  |   6 +-
>  arch/arm/mach-rockchip/board.c  |   6 +-
>  board/amazon/kc1/kc1.c  |   6 +-
>  board/lg/sniper/sniper.c|   6 +-
>  board/ti/am57xx/board.c |   6 +-
>  board/ti/dra7xx/evm.c   |   6 +-
>  cmd/usb_mass_storage.c  |   2 +-
>  common/spl/spl_sdp.c|   2 +
>  common/update.c |   6 +-
>  configs/qemu_arm64_defconfig|   9 +
>  configs/qemu_arm_defconfig  |   9 +
>  doc/android/fastboot.rst|  19 +++
>  drivers/dfu/Kconfig |   1 +
>  drivers/dfu/dfu_ram.c   |   7 +-
>  drivers/fastboot/Kconfig|  12 ++
>  drivers/fastboot/Makefile   |   1 +
>  drivers/fastboot/fb_bcb_impl.c  |  43 +
>  drivers/fastboot/fb_command.c   |  40 -
>  drivers/fastboot/fb_common.c|   2 +-
>  drivers/fastboot/fb_getvar.c|   4 +-
>  drivers/fastboot/fb_mmc.c   |  75 -
>  drivers/usb/eth/r8152.c | 223 -
>  drivers/usb/eth/r8152.h |  59 +--
>  drivers/usb/eth/r8152_fw.c  | 228 +++---
>  drivers/usb/gadget/Kconfig  |   6 +
>  drivers/usb/gadget/Makefile |   1 +
>  drivers/usb/gadget/ci_udc.c |   7 +
>  drivers/usb/gadget/f_fastboot.c |   6 +-
>  drivers/usb/gadget/f_mass_storage.c |   6 +-
>  drivers/usb/gadget/f_sdp.c  | 219 +
>  drivers/usb/gadget/gadget_chips.h   |   8 +
>  drivers/usb/gadget/max3420_udc.c| 875
> +
>  drivers/usb/host/usb-uclass.c   |  18 ++
>  include/dfu.h   |   2 +-
>  include/fastboot.h  |  23 ++-
>  include/usb.h   |   9 +
>  include/usb_mass_storage.h  |   2 +-
>  net/fastboot.c  |   2 +
>  39 files changed, 1867 insertions(+), 101 deletions(-)
>  create mode 100644 drivers/fastboot/fb_bcb_impl.c
>  create mode 100644 drivers/usb/gadget/max3420_udc.c

This feels like a lot.  Is it really a good time to take these for
v2020.10 or should I put them in -next, next week when it opens?

-- 
Tom


signature.asc
Description: PGP signature


[RFC, v2] SquashFS not compiling due to missing __udivdi3 and __umoddi3

2020-09-03 Thread Mauro Condarelli
Second update.
It turns out I was  bit too aggressive in my "fix".
Unfortunately that is not cause of malfunction and
code is still unable to load files.
Any hint on how to proceed would be useful, current
plan is to add printouts to code to trace what happens,
but that is going to be a real PITA.

Thanks in Advance
Mauro


>From 74ba63e93099515950a8dcd57162d8f5b98b9e5d Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Thu, 3 Sep 2020 08:37:58 +0200
Subject: [PATCH 4/4] Fix missing __udivdi3 in SquashFS implementation.

Signed-off-by: Mauro Condarelli 
---
 fs/squashfs/sqfs.c   | 40 
 fs/squashfs/sqfs_inode.c |  8 
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index f67f7c4a40..2abb603afc 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sqfs_decompressor.h"
 #include "sqfs_filesystem.h"
@@ -82,13 +83,16 @@ static int sqfs_count_tokens(const char *filename)
  */
 static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 *offset)
 {
-    u64 start_, table_size;
+    u64 start_, table_size, blks;
 
 table_size = le64_to_cpu(end) - le64_to_cpu(start);
-    start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
+    start_ = le64_to_cpu(start);
+    do_div(start_, ctxt.cur_dev->blksz);
 *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
 
-    return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
+    blks = table_size + *offset;
+    if (do_div(blks, ctxt.cur_dev->blksz)) blks++;
+    return blks;
 }
 
 /*
@@ -109,8 +113,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
 if (inode_fragment_index >= get_unaligned_le32(>fragments))
     return -EINVAL;
 
-    start = get_unaligned_le64(>fragment_table_start) /
-        ctxt.cur_dev->blksz;
+    start = get_unaligned_le64(>fragment_table_start);
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
               sblk->export_table_start,
               _offset);
@@ -135,7 +139,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
 start_block = get_unaligned_le64(table + table_offset + block *
                  sizeof(u64));
 
-    start = start_block / ctxt.cur_dev->blksz;
+    start = start_block;
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
               sblk->fragment_table_start, _offset);
 
@@ -641,8 +646,8 @@ static int sqfs_read_inode_table(unsigned char 
**inode_table)
 
 table_size = get_unaligned_le64(>directory_table_start) -
     get_unaligned_le64(>inode_table_start);
-    start = get_unaligned_le64(>inode_table_start) /
-        ctxt.cur_dev->blksz;
+    start = get_unaligned_le64(>inode_table_start);
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
               sblk->directory_table_start, _offset);
 
@@ -725,8 +730,8 @@ static int sqfs_read_directory_table(unsigned char 
**dir_table, u32 **pos_list)
 /* DIRECTORY TABLE */
 table_size = get_unaligned_le64(>fragment_table_start) -
     get_unaligned_le64(>directory_table_start);
-    start = get_unaligned_le64(>directory_table_start) /
-        ctxt.cur_dev->blksz;
+    start = get_unaligned_le64(>directory_table_start);
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
               sblk->fragment_table_start, _offset);
 
@@ -1159,7 +1164,7 @@ static int sqfs_get_regfile_info(struct 
squashfs_reg_inode *reg,
     if (fentry->size < 1 || fentry->start < 0)
         return -EINVAL;
 } else {
-        datablk_count = DIV_ROUND_UP(finfo->size, le32_to_cpu(blksz));
+    datablk_count = DIV_ROUND_UP(finfo->size, le32_to_cpu(blksz));
 }
 
 finfo->blk_sizes = malloc(datablk_count * sizeof(u32));
@@ -1328,11 +1333,12 @@ int sqfs_read(const char *filename, void *buf, loff_t 
offset, loff_t len,
 }
 
 for (j = 0; j < datablk_count; j++) {
-        start = data_offset / ctxt.cur_dev->blksz;
+        start = data_offset;
+        do_div(start, ctxt.cur_dev->blksz);
     table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
     table_offset = data_offset - (start * ctxt.cur_dev->blksz);
-        n_blks = DIV_ROUND_UP(table_size + table_offset,
-                  ctxt.cur_dev->blksz);
+        n_blks = table_size + table_offset;
+        if (do_div(n_blks, ctxt.cur_dev->blksz)) n_blks++;
 
     data_buffer = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
 
@@ -1382,10 +1388,12 @@ int sqfs_read(const char *filename, void *buf, loff_t 
offset, loff_t len,
     goto free_buffer;
 }
 
-    start = frag_entry.start / ctxt.cur_dev->blksz;
+    start = frag_entry.start;
+    do_div(start, ctxt.cur_dev->blksz);
 table_size = SQFS_BLOCK_SIZE(frag_entry.size);
 

[PATCH v2] buildman: Use git worktrees instead of git clones when possible

2020-09-03 Thread Alper Nebi Yasak
This patch makes buildman create linked working trees instead of clones
of the source repository, but keeps updating the older clones of the
repository that might already exist. These worktrees share "everything
except working directory specific files such as HEAD, index, etc." with
the source repository. See the git-worktree(1) manual page for more
information.

If git-worktree isn't available, silently falls back to cloning the
repository.

Signed-off-by: Alper Nebi Yasak 
---
I used 'git worktree list's return code, since 'git worktree' returns
non-zero (prints usage) even if it's available.

This does fall back to git clone on my Ubuntu 14.04 amd64 VM, but all
the builds instantly give an error about the Makefile even before this
patch. The buildman parts are working as far as I can tell.

Changes in v2:
- Fall back to cloning if git-worktree isn't available
- Add a gitutil.CheckWorktreeIsAvailable(git_dir) function
- Refactor the _PrepareThread changes
- Make _PrepeareThread's setup_git argument accept 'clone' or 'worktree'
- Some comment and docstring changes

v1: https://patchwork.ozlabs.org/project/uboot/list/?series=199060

 tools/buildman/builder.py   | 48 ++---
 tools/buildman/func_test.py |  2 ++
 tools/patman/gitutil.py | 42 
 3 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index dbb75b35c1..c93946842a 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -1541,41 +1541,73 @@ class Builder:
 """Prepare the working directory for a thread.
 
 This clones or fetches the repo into the thread's work directory.
+Optionally, it can create a linked working tree of the repo in the
+thread's work directory instead.
 
 Args:
 thread_num: Thread number (0, 1, ...)
-setup_git: True to set up a git repo clone
+setup_git:
+   'clone' to set up a git clone
+   'worktree' to set up a git worktree
 """
 thread_dir = self.GetThreadDir(thread_num)
 builderthread.Mkdir(thread_dir)
 git_dir = os.path.join(thread_dir, '.git')
 
-# Clone the repo if it doesn't already exist
-# TODO(sjg@chromium): Perhaps some git hackery to symlink instead, so
-# we have a private index but uses the origin repo's contents?
+# Create a worktree or a git repo clone for this thread if it
+# doesn't already exist
 if setup_git and self.git_dir:
 src_dir = os.path.abspath(self.git_dir)
-if os.path.exists(git_dir):
+if os.path.isdir(git_dir):
+# This is a clone of the src_dir repo, we can keep using
+# it but need to fetch from src_dir.
 Print('\rFetching repo for thread %d' % thread_num,
   newline=False)
 gitutil.Fetch(git_dir, thread_dir)
 terminal.PrintClear()
-else:
+elif os.path.isfile(git_dir):
+# This is a worktree of the src_dir repo, we don't need to
+# create it again or update it in any way.
+pass
+elif os.path.exists(git_dir):
+# Don't know what could trigger this, but we probably
+# can't create a git worktree/clone here.
+raise ValueError('Git dir %s exists, but is not a file '
+ 'or a directory.' % git_dir)
+elif setup_git == 'worktree':
+Print('\rChecking out worktree for thread %d' % thread_num,
+  newline=False)
+gitutil.AddWorktree(src_dir, thread_dir)
+terminal.PrintClear()
+elif setup_git == 'clone' or setup_git == True:
 Print('\rCloning repo for thread %d' % thread_num,
   newline=False)
 gitutil.Clone(src_dir, thread_dir)
 terminal.PrintClear()
+else:
+raise ValueError("Can't setup git repo with %s." % setup_git)
 
 def _PrepareWorkingSpace(self, max_threads, setup_git):
 """Prepare the working directory for use.
 
-Set up the git repo for each thread.
+Set up the git repo for each thread. Creates a linked working tree
+if git-worktree is available, or clones the repo if it isn't.
 
 Args:
 max_threads: Maximum number of threads we expect to need.
-setup_git: True to set up a git repo clone
+setup_git: True to set up a git worktree or a git clone
 """
 builderthread.Mkdir(self._working_dir)
+if setup_git and self.git_dir:
+src_dir = os.path.abspath(self.git_dir)
+if gitutil.CheckWorktreeIsAvailable(src_dir):
+setup_git = 'worktree'
+# If we 

Re: [PATCH 0/2] Add support for loading images above 4GB

2020-09-03 Thread Michal Simek
Hi,

On 03. 09. 20 13:16, Heinrich Schuchardt wrote:
> On 9/3/20 1:03 PM, Michal Simek wrote:
>> Hi,
>>
>> We have several use cases where customers want to partition memory by
>> putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for
>> others CPU in the systems (like R5) or for secure sw.
>> Currently there is limitation in SPL to record load/entry addresses in
>> 64bit format because they are recorded in 32bit only.
>> This series add support for it.
>> Patches have been tested on Xilinx ZynqMP zcu102 board in SD bootmode with
>> images generated by binman. Because u-boot is using
>> CONFIG_POSITION_INDEPENDENT it can be put to others 4k aligned addresses
>> and there is no real need to build it to certain offset.
>>
>> Thanks,
>> Michal
> 
> Hello Michal,
> 
> does this series require changes to doc/uImage.FIT/source_file_format.txt?

I am not changing fit format. I am just changing how SPL records
loadables in DT fit-images node. And also series is using FIT functions
for reading these properties (at least in this version).

Thanks,
Michal


Re: [PATCH] configs: powerpc: Don't set CONFIG_ENV_ADDR for T2080RDB_SPIFLASH

2020-09-03 Thread Tom Rini
On Thu, Sep 03, 2020 at 12:02:06PM +1200, Chris Packham wrote:

> Setting CONFIG_ENV_ADDR to something other than 0 stops gd->env_addr
> from being allocated dynamically. When the environment is in SPI we need
> it to be allocated as we can't use a direct memory mapped address.
> 
> Signed-off-by: Chris Packham 
> ---
> 
>  configs/T2080RDB_SPIFLASH_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configs/T2080RDB_SPIFLASH_defconfig 
> b/configs/T2080RDB_SPIFLASH_defconfig
> index 62cbab1f0734..ba4ac1010502 100644
> --- a/configs/T2080RDB_SPIFLASH_defconfig
> +++ b/configs/T2080RDB_SPIFLASH_defconfig
> @@ -50,7 +50,6 @@ 
> CONFIG_MTDPARTS_DEFAULT="mtdparts=fe800.nor:1m(uboot),5m(kernel),128k(dtb),9
>  CONFIG_OF_CONTROL=y
>  CONFIG_ENV_OVERWRITE=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
> -CONFIG_ENV_ADDR=0xFFFC9000
>  CONFIG_DM=y
>  CONFIG_FSL_CAAM=y
>  CONFIG_DM_I2C=y

Thanks for figuring that out.  There's a handful of _SPIFLASH defconfigs
that do the exact same thing, from the same conversion (I probably did
it) to defconfig.  It's likely that they're all wrong, yes?

-- 
Tom


signature.asc
Description: PGP signature


[PULL] u-boot-sh/master

2020-09-03 Thread Marek Vasut
The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:

  MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
17:11:24 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-sh.git master

for you to fetch changes up to f5ba5c90d4b9c4d691a62eaca47dc095eefba8b1:

  serial: sh: Improve FIFO empty check on RX (2020-09-01 14:46:41 +0200)


Marek Vasut (1):
  serial: sh: Improve FIFO empty check on RX

 drivers/serial/serial_sh.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)


[PULL] u-boot-usb/master

2020-09-03 Thread Marek Vasut
Mostly DFU fixes and r8152 fixes below:

The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:

  MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
17:11:24 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-usb.git master

for you to fetch changes up to 293a6dfeb96129abebf1ad927fa9aedf03a66d34:

  fastboot: getvar: fix partition-size return value (2020-09-01 14:47:43
+0200)


Filip Brozovic (1):
  fastboot: Support defining raw partitions without a partition table

Frank Li (1):
  sdp: call board_usb_init at spl_sdp_load_image

Gary Bisson (1):
  fastboot: getvar: fix partition-size return value

Hayes Wang (4):
  eth/r8152: reset bmu after disabling Tx/Rx
  eth/r8152: reset PHY after setting it
  eth/r8152: modify rtl_clear_bp function
  eth/r8152: support RTL8153B/RTL8154B

Heinrich Schuchardt (4):
  dfu: fix typo parameteres
  dfu: DFU_MTD depends on CMD_MTDPARTS
  configs: qemu: enable dfu testing
  dfu: fix dfu tftp on sandbox

Jassi Brar (1):
  usb: max3420: add the gadget driver

Peng Fan (2):
  f_sdp: Support searching and loading FIT or container image
  spl: add g_dnl_get_board_bcd_device_number

Roman Kovalivskyi (3):
  fastboot: Extend fastboot_set_reboot_flag with reboot reason
  fastboot: Add support for 'reboot fastboot' command
  fastboot: Add default fastboot_set_reboot_flag implementation

Sherry Sun (2):
  f_sdp: Add EP1_OUT as default data receive pipe in sdp
  f_sdp: Change bInterval of interrupt endpoint to 3

Ye Li (4):
  usb: gadget: Fix controller index in UMS
  usb: ci_udc: Add function to remove usb device
  f_sdp: Add high speed endpoint descriptor
  f_sdp: Fix wrong usb request size

yurii.pidhornyi (1):
  fastboot: Fix fastboot reboot fail by changing functions order

 arch/arm/mach-imx/spl.c |   6 +
 arch/arm/mach-meson/board-common.c  |   6 +-
 arch/arm/mach-rockchip/board.c  |   6 +-
 board/amazon/kc1/kc1.c  |   6 +-
 board/lg/sniper/sniper.c|   6 +-
 board/ti/am57xx/board.c |   6 +-
 board/ti/dra7xx/evm.c   |   6 +-
 cmd/usb_mass_storage.c  |   2 +-
 common/spl/spl_sdp.c|   2 +
 common/update.c |   6 +-
 configs/qemu_arm64_defconfig|   9 +
 configs/qemu_arm_defconfig  |   9 +
 doc/android/fastboot.rst|  19 +++
 drivers/dfu/Kconfig |   1 +
 drivers/dfu/dfu_ram.c   |   7 +-
 drivers/fastboot/Kconfig|  12 ++
 drivers/fastboot/Makefile   |   1 +
 drivers/fastboot/fb_bcb_impl.c  |  43 +
 drivers/fastboot/fb_command.c   |  40 -
 drivers/fastboot/fb_common.c|   2 +-
 drivers/fastboot/fb_getvar.c|   4 +-
 drivers/fastboot/fb_mmc.c   |  75 -
 drivers/usb/eth/r8152.c | 223 -
 drivers/usb/eth/r8152.h |  59 +--
 drivers/usb/eth/r8152_fw.c  | 228 +++---
 drivers/usb/gadget/Kconfig  |   6 +
 drivers/usb/gadget/Makefile |   1 +
 drivers/usb/gadget/ci_udc.c |   7 +
 drivers/usb/gadget/f_fastboot.c |   6 +-
 drivers/usb/gadget/f_mass_storage.c |   6 +-
 drivers/usb/gadget/f_sdp.c  | 219 +
 drivers/usb/gadget/gadget_chips.h   |   8 +
 drivers/usb/gadget/max3420_udc.c| 875
+
 drivers/usb/host/usb-uclass.c   |  18 ++
 include/dfu.h   |   2 +-
 include/fastboot.h  |  23 ++-
 include/usb.h   |   9 +
 include/usb_mass_storage.h  |   2 +-
 net/fastboot.c  |   2 +
 39 files changed, 1867 insertions(+), 101 deletions(-)
 create mode 100644 drivers/fastboot/fb_bcb_impl.c
 create mode 100644 drivers/usb/gadget/max3420_udc.c


Re: [PATCH v2 7/7] riscv: Update SiFive device tree for new CLINT driver

2020-09-03 Thread Anup Patel
On Thu, Sep 3, 2020 at 4:23 PM Sean Anderson  wrote:
>
> On 9/3/20 1:01 AM, Anup Patel wrote:
> > On Thu, Sep 3, 2020 at 8:19 AM Bin Meng  wrote:
> >>
> >> Hi Anup,
> >>
> >> On Thu, Sep 3, 2020 at 10:46 AM Anup Patel  wrote:
> >>>
> >>> On Thu, Sep 3, 2020 at 7:32 AM Bin Meng  wrote:
> 
>  Hi Anup,
> 
>  On Tue, Aug 18, 2020 at 6:03 PM Sean Anderson  wrote:
> >
> > On 8/18/20 5:22 AM, Bin Meng wrote:
> >> +Anup Patel
> >>
> >> On Wed, Jul 29, 2020 at 5:57 PM Sean Anderson  
> >> wrote:
> >>>
> >>> We may need to add a clock-frequency binding like for the K210.
> >>>
> >>> Signed-off-by: Sean Anderson 
> >>> ---
> >>> This patch builds but has NOT been tested.
> >>>
> >>> Changes in v2:
> >>> - Fix SiFive CLINT not getting tick-rate from rtcclk
> >>>
> >>>  arch/riscv/dts/fu540-c000-u-boot.dtsi   | 8 ++--
> >>>  arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4 
> >>>  2 files changed, 10 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi 
> >>> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>> index afdb4f4402..f126d3e0b3 100644
> >>> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>> @@ -53,9 +53,13 @@
> >>> reg = <0x0 0x1007 0x0 0x1000>;
> >>> fuse-count = <0x1000>;
> >>> };
> >>> -   clint@200 {
> >>> +   clint: clint@200 {
> >>> compatible = "riscv,clint0";
> >>> -   interrupts-extended = <_intc 3 
> >>> _intc 7 _intc 3 _intc 7 _intc 3 _intc 7 
> >>> _intc 3 _intc 7 _intc 3 _intc 7>;
> >>> +   interrupts-extended = <_intc 3 
> >>> _intc 7
> >>> +  _intc 3 
> >>> _intc 7
> >>> +  _intc 3 
> >>> _intc 7
> >>> +  _intc 3 
> >>> _intc 7
> >>> +  _intc 3 
> >>> _intc 7>;
> >>> reg = <0x0 0x200 0x0 0xc>;
> >>> u-boot,dm-spl;
> >>> };
> >>> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
> >>> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> >>> index e037150520..3275bb1f12 100644
> >>> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> >>> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> >>> @@ -26,6 +26,10 @@
> >>>
> >>>  };
> >>>
> >>> + {
> >>> +   clocks = <>;
> >>> +};
> >>
> >> Can we consider making this property a standard property by the kernel
> >> upstream? How does the kernel CLINT timer driver determine its running
> >> frequency?
> >
> > Currently it gets it from /cpus/timebase-frequency.
> 
>  What's your comment on this? I think this should go upstream to the
>  standard bindings.
> >>>
> >>> My apologies for delay. Too many mailing list to track.
> >>>
> >>> I think "clocks" should be an optional DT property for CLINT driver (both
> >>> Linux and U-Boot). If "clocks" is not available then we should fallback to
> >>> "/cpus/timebase-frequency"
> >>>
> >>
> >> Agreed. The question is whether this should be mentioned in the DT
> >> bindings doc in the kernel tree?
> >
> > Yes, the "clocks" DT property should be updated in kernel DT bindings doc
> > and kernel CLINT driver should also prefer "clocks" DT property when 
> > available.
> >
> > Regards,
> > Anup
>
> Should clock-frequency be used as well, or should that be left for 
> timebase-frequency?

Not sure about clock-frequency DT property. I think very few linux clocksource
drivers use "clock-frequency" DT property.

Probably it's fine to first check for "clocks" and "clock-frequency" before
falling back to "timebase-frequency".

Regards,
Anup

>
> --Sean


Re: RPi4 U-Boot freeze

2020-09-03 Thread Stefan Agner
Any thoughts on this issue?

Just to be sure, I did some memory testing on the 2GB module, but no
issues found.

I still somehow suspected that something else might be wrong with my
hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the
very same with that:

U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +)

DRAM:  3.9 GiB


I still think there is something wrong with caching. From what I
understand caches are enabled by the RPi (4) firmware. Is it safe to run
32-bit ARM U-Boot with enabled caches?

--
Stefan

On 2020-08-23 19:06, Stefan Agner wrote:
> Hi,
> 
> I noticed a quite common freeze when running 32-bit U-Boot 2020.01
> (rpi_4_32b_defconfig) on a 2GB RPi4 model:
> 
> U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +)
> 
> DRAM:  1.9 GiB
> 
> 
> This happens fairly often, I would say 4 out of 5 boot tries. However,
> if it boots, everything seems to run fine.
> 
> The issue seems to go away when using 2020.04 or any newer release,
> however, when trying to find the actual patch fixing the issue using git
> bisect I ended up with a MMC merge request which really seems unrelated
> (36bdcf7f3b). It seems that the problem is quite evasive and disappears
> if certain structure are aligned differently etc.
> 
> Enabling initcall debugging showed that U-Boot crashes right after
> relocation:
> 
> ...
> initcall: 00016f2c
> 
> RAM Configuration:
> Bank #0: 0 948 MiB
> Bank #1: 4000 1 GiB
> Bank #2: 0 0 Bytes
> Bank #3: 0 0 Bytes
> 
> DRAM:  1.9 GiB
> initcall: 00016bb8
> New Stack Pointer is: 3af6d9e0
> initcall: 00016da4
> initcall: 00016ef0
> initcall: 00016ef8
> initcall: 00016d38
> Relocation Offset is: 3b375000
> Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0
> initcall: 00016ec8 [clear_bss]
> initcall: 0004465c [display_options?? only appears sometimes]
> 
> 
> I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to
> disappear. But to be 100% certain that it is cache related, I used my
> original configuration (which is known to "reliably" freeze), and
> replaced 00016ec8 with 8688 manually in the binary, essentially
> swapping out function pointers in "init_sequence_f" [8688 is
> cleanup_before_linux, which flushes and disables I-cache/D-cache]. And
> indeed, that hacked up binary does boot reliably every time:
> 
> ...
> initcall: 00016f2c
> 
> RAM Configuration:
> Bank #0: 0 948 MiB
> Bank #1: 4000 1 GiB
> Bank #2: 0 0 Bytes
> Bank #3: 0 0 Bytes
> 
> DRAM:  1.9 GiB
> initcall: 00016bb8
> New Stack Pointer is: 3af6d9e0
> initcall: 00016da4
> initcall: 00016ef0
> initcall: 00016ef8
> initcall: 00016d38
> Relocation Offset is: 3b375000
> Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0
> initcall: 8688
> initcall: 3b38c10c
> initcall: 3b38c114
> initcall: 000172e0 (relocated to 3b38c2e0)
> initcall: 0001712c (relocated to 3b38c12c)
> ...
> 
> From what I understand on RPi4 caches are enabled when entering U-Boot.
> I was wondering if the relocation code really can handle that?
> 
> --
> Stefan


Re: [PATCH 0/2] Add support for loading images above 4GB

2020-09-03 Thread Heinrich Schuchardt
On 9/3/20 1:03 PM, Michal Simek wrote:
> Hi,
>
> We have several use cases where customers want to partition memory by
> putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for
> others CPU in the systems (like R5) or for secure sw.
> Currently there is limitation in SPL to record load/entry addresses in
> 64bit format because they are recorded in 32bit only.
> This series add support for it.
> Patches have been tested on Xilinx ZynqMP zcu102 board in SD bootmode with
> images generated by binman. Because u-boot is using
> CONFIG_POSITION_INDEPENDENT it can be put to others 4k aligned addresses
> and there is no real need to build it to certain offset.
>
> Thanks,
> Michal

Hello Michal,

does this series require changes to doc/uImage.FIT/source_file_format.txt?

Best regards

Heinrich

>
>
> Michal Simek (2):
>   spl: Use standard FIT entries
>   spl: fdt: Record load/entry fit-images entries in 64bit format
>
>  common/fdt_support.c | 9 ++---
>  common/spl/spl_atf.c | 7 ---
>  common/spl/spl_fit.c | 6 +-
>  3 files changed, 11 insertions(+), 11 deletions(-)
>



[PATCH] arm64: zynqmp: Change bl2_plat_get_bl31_params() guarding

2020-09-03 Thread Michal Simek
It was protected just for SPL_OS_BOOT but this function is only called when
SPL_ATF is enabled that's why change macro name.

Signed-off-by: Michal Simek 
---

 arch/arm/mach-zynqmp/handoff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-zynqmp/handoff.c b/arch/arm/mach-zynqmp/handoff.c
index 64e5320acc68..7d7ab9da6ec2 100644
--- a/arch/arm/mach-zynqmp/handoff.c
+++ b/arch/arm/mach-zynqmp/handoff.c
@@ -65,7 +65,7 @@ struct xfsbl_atf_handoff_params {
struct xfsbl_partition partition[FSBL_MAX_PARTITIONS];
 };
 
-#ifdef CONFIG_SPL_OS_BOOT
+#ifdef CONFIG_SPL_ATF
 struct bl31_params *bl2_plat_get_bl31_params(uintptr_t bl32_entry,
 uintptr_t bl33_entry,
 uintptr_t fdt_addr)
-- 
2.28.0



[PATCH 2/2] spl: fdt: Record load/entry fit-images entries in 64bit format

2020-09-03 Thread Michal Simek
The commit 9f45aeb93727 ("spl: fit: implement fdt_record_loadable") which
introduced fdt_record_loadable() state there spl_fit.c is not 64bit safe.
Based on my tests on Xilinx ZynqMP zcu102 platform there shouldn't be a
problem to record these addresses in 64bit format.
The patch adds support for systems which need to load images above 4GB.

Signed-off-by: Michal Simek 
---

 common/fdt_support.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index b8a8768a2147..5ae75df3c658 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -611,14 +611,9 @@ int fdt_record_loadable(void *blob, u32 index, const char 
*name,
if (node < 0)
return node;
 
-   /*
-* We record these as 32bit entities, possibly truncating addresses.
-* However, spl_fit.c is not 64bit safe either: i.e. we should not
-* have an issue here.
-*/
-   fdt_setprop_u32(blob, node, "load", load_addr);
+   fdt_setprop_u64(blob, node, "load", load_addr);
if (entry_point != -1)
-   fdt_setprop_u32(blob, node, "entry", entry_point);
+   fdt_setprop_u64(blob, node, "entry", entry_point);
fdt_setprop_u32(blob, node, "size", size);
if (type)
fdt_setprop_string(blob, node, "type", type);
-- 
2.28.0



[PATCH 1/2] spl: Use standard FIT entries

2020-09-03 Thread Michal Simek
SPL is creating fit-images DT node when loadables are recorded in selected
configuration. Entries which are created are using entry-point and
load-addr property names. But there shouldn't be a need to use non standard
properties because entry/load are standard FIT properties. But using
standard FIT properties enables option to use generic FIT functions to
descrease SPL size. Here is result for ZynqMP virt configuration:
xilinx_zynqmp_virt: spl/u-boot-spl:all -82 spl/u-boot-spl:rodata -22 
spl/u-boot-spl:text -60

The patch causes change in run time fit image record.
Before:
fit-images {
uboot {
os = "u-boot";
type = "firmware";
size = <0xfd520>;
entry-point = <0x800>;
load-addr = <0x800>;
};
};

After:
fit-images {
uboot {
os = "u-boot";
type = "firmware";
size = <0xfd520>;
entry = <0x800>;
load = <0x800>;
};
};

Replacing calling fdt_getprop_u32() by fit_image_get_entry/load() also
enables support for reading entry/load properties recorded in 64bit format.

Signed-off-by: Michal Simek 
---

Would be good to know history of fit-images and it's property names but
there shouldn't be a need to use non standard names where we have
FIT_*_PROP recorded as macros in include/image.h.

Concern regarding backward compatibility is definitely valid but not sure
how many systems can be affected by this change.

Adding temporary support for entry-point/load-addr is also possible.
Or second way around is to create new wrappers as
fit_image_get_entry_point()/fit_image_get_load_addr() or
call fit_image_get_address() directly.

---
 common/fdt_support.c | 4 ++--
 common/spl/spl_atf.c | 7 ---
 common/spl/spl_fit.c | 6 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index a565b470f81e..b8a8768a2147 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -616,9 +616,9 @@ int fdt_record_loadable(void *blob, u32 index, const char 
*name,
 * However, spl_fit.c is not 64bit safe either: i.e. we should not
 * have an issue here.
 */
-   fdt_setprop_u32(blob, node, "load-addr", load_addr);
+   fdt_setprop_u32(blob, node, "load", load_addr);
if (entry_point != -1)
-   fdt_setprop_u32(blob, node, "entry-point", entry_point);
+   fdt_setprop_u32(blob, node, "entry", entry_point);
fdt_setprop_u32(blob, node, "size", size);
if (type)
fdt_setprop_string(blob, node, "type", type);
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index b54b4f0d22e2..9bd25f6b32c1 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -132,10 +132,11 @@ static int spl_fit_images_find(void *blob, int os)
 uintptr_t spl_fit_images_get_entry(void *blob, int node)
 {
ulong  val;
+   int ret;
 
-   val = fdt_getprop_u32(blob, node, "entry-point");
-   if (val == FDT_ERROR)
-   val = fdt_getprop_u32(blob, node, "load-addr");
+   ret = fit_image_get_entry(blob, node, );
+   if (ret)
+   ret = fit_image_get_load(blob, node, );
 
debug("%s: entry point 0x%lx\n", __func__, val);
return val;
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 365104fe0288..b69b3948841f 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -332,9 +332,13 @@ static int spl_load_fit_image(struct spl_load_info *info, 
ulong sector,
}
 
if (image_info) {
+   ulong entry_point;
+
image_info->load_addr = load_addr;
image_info->size = length;
-   image_info->entry_point = fdt_getprop_u32(fit, node, "entry");
+
+   if (!fit_image_get_entry(fit, node, _point))
+   image_info->entry_point = entry_point;
}
 
return 0;
-- 
2.28.0



[PATCH 0/2] Add support for loading images above 4GB

2020-09-03 Thread Michal Simek
Hi,

We have several use cases where customers want to partition memory by
putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for
others CPU in the systems (like R5) or for secure sw.
Currently there is limitation in SPL to record load/entry addresses in
64bit format because they are recorded in 32bit only.
This series add support for it.
Patches have been tested on Xilinx ZynqMP zcu102 board in SD bootmode with
images generated by binman. Because u-boot is using
CONFIG_POSITION_INDEPENDENT it can be put to others 4k aligned addresses
and there is no real need to build it to certain offset.

Thanks,
Michal


Michal Simek (2):
  spl: Use standard FIT entries
  spl: fdt: Record load/entry fit-images entries in 64bit format

 common/fdt_support.c | 9 ++---
 common/spl/spl_atf.c | 7 ---
 common/spl/spl_fit.c | 6 +-
 3 files changed, 11 insertions(+), 11 deletions(-)

-- 
2.28.0



[PATCH 7/8] sunxi: DT: A64: update device tree files

2020-09-03 Thread Samuel Holland
Import updated device trees from Linux v5.9-rc3. This picks up new
hardware (PinePhone, PineTab); and it drops the U-Boot specific DTSI
files for the Pinebook and the Teres-I, since the ANX6345 bridge is
now supported upstream.

A couple of headers needed updates for recently-added hardware support.

Signed-off-by: Samuel Holland 
---
 arch/arm/dts/Makefile |   4 +
 arch/arm/dts/axp803.dtsi  |  82 +--
 arch/arm/dts/sun50i-a64-amarula-relic.dts | 109 +++-
 arch/arm/dts/sun50i-a64-bananapi-m64.dts  | 118 ++--
 arch/arm/dts/sun50i-a64-cpu-opp.dtsi  |  75 +++
 arch/arm/dts/sun50i-a64-nanopi-a64.dts|  70 +--
 .../dts/sun50i-a64-oceanic-5205-5inmfd.dts|  31 +-
 arch/arm/dts/sun50i-a64-olinuxino-emmc.dts|  12 +-
 arch/arm/dts/sun50i-a64-olinuxino.dts | 113 ++--
 arch/arm/dts/sun50i-a64-orangepi-win.dts  | 127 +++--
 arch/arm/dts/sun50i-a64-pine64-lts.dts|   7 +-
 arch/arm/dts/sun50i-a64-pine64-plus.dts   |  52 +-
 arch/arm/dts/sun50i-a64-pine64.dts|  97 ++--
 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi  |  17 -
 arch/arm/dts/sun50i-a64-pinebook.dts  | 237 ++--
 arch/arm/dts/sun50i-a64-pinephone-1.0.dts |  11 +
 arch/arm/dts/sun50i-a64-pinephone-1.1.dts |  30 +
 arch/arm/dts/sun50i-a64-pinephone-1.2.dts |  40 ++
 arch/arm/dts/sun50i-a64-pinephone.dtsi| 429 ++
 arch/arm/dts/sun50i-a64-pinetab.dts   | 460 +++
 arch/arm/dts/sun50i-a64-sopine-baseboard.dts  | 113 ++--
 arch/arm/dts/sun50i-a64-sopine.dtsi   |  69 +--
 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi   |  41 --
 arch/arm/dts/sun50i-a64-teres-i.dts   | 138 -
 arch/arm/dts/sun50i-a64.dtsi  | 532 ++
 include/dt-bindings/clock/sun50i-a64-ccu.h|   4 +-
 include/dt-bindings/clock/sun8i-de2.h |   3 +
 include/dt-bindings/reset/sun8i-de2.h |   1 +
 28 files changed, 2390 insertions(+), 632 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-a64-cpu-opp.dtsi
 delete mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.0.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.1.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.2.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone.dtsi
 create mode 100644 arch/arm/dts/sun50i-a64-pinetab.dts
 delete mode 100644 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f8f529435bf..57ef94450a1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -608,6 +608,10 @@ dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-pine64-plus.dtb \
sun50i-a64-pine64.dtb \
sun50i-a64-pinebook.dtb \
+   sun50i-a64-pinephone-1.0.dtb \
+   sun50i-a64-pinephone-1.1.dtb \
+   sun50i-a64-pinephone-1.2.dtb \
+   sun50i-a64-pinetab.dtb \
sun50i-a64-sopine-baseboard.dtb \
sun50i-a64-teres-i.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
diff --git a/arch/arm/dts/axp803.dtsi b/arch/arm/dts/axp803.dtsi
index e5eae8bafc4..10e9186a76b 100644
--- a/arch/arm/dts/axp803.dtsi
+++ b/arch/arm/dts/axp803.dtsi
@@ -1,44 +1,5 @@
-/*
- * Copyright 2017 Icenowy Zheng 
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- *  a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- *  b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS 

Re: [PATCH v2 7/7] riscv: Update SiFive device tree for new CLINT driver

2020-09-03 Thread Sean Anderson
On 9/3/20 1:01 AM, Anup Patel wrote:
> On Thu, Sep 3, 2020 at 8:19 AM Bin Meng  wrote:
>>
>> Hi Anup,
>>
>> On Thu, Sep 3, 2020 at 10:46 AM Anup Patel  wrote:
>>>
>>> On Thu, Sep 3, 2020 at 7:32 AM Bin Meng  wrote:

 Hi Anup,

 On Tue, Aug 18, 2020 at 6:03 PM Sean Anderson  wrote:
>
> On 8/18/20 5:22 AM, Bin Meng wrote:
>> +Anup Patel
>>
>> On Wed, Jul 29, 2020 at 5:57 PM Sean Anderson  wrote:
>>>
>>> We may need to add a clock-frequency binding like for the K210.
>>>
>>> Signed-off-by: Sean Anderson 
>>> ---
>>> This patch builds but has NOT been tested.
>>>
>>> Changes in v2:
>>> - Fix SiFive CLINT not getting tick-rate from rtcclk
>>>
>>>  arch/riscv/dts/fu540-c000-u-boot.dtsi   | 8 ++--
>>>  arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4 
>>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi 
>>> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
>>> index afdb4f4402..f126d3e0b3 100644
>>> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
>>> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
>>> @@ -53,9 +53,13 @@
>>> reg = <0x0 0x1007 0x0 0x1000>;
>>> fuse-count = <0x1000>;
>>> };
>>> -   clint@200 {
>>> +   clint: clint@200 {
>>> compatible = "riscv,clint0";
>>> -   interrupts-extended = <_intc 3 _intc 
>>> 7 _intc 3 _intc 7 _intc 3 _intc 7 _intc 3 
>>> _intc 7 _intc 3 _intc 7>;
>>> +   interrupts-extended = <_intc 3 _intc 7
>>> +  _intc 3 _intc 7
>>> +  _intc 3 _intc 7
>>> +  _intc 3 _intc 7
>>> +  _intc 3 _intc 
>>> 7>;
>>> reg = <0x0 0x200 0x0 0xc>;
>>> u-boot,dm-spl;
>>> };
>>> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
>>> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>>> index e037150520..3275bb1f12 100644
>>> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>>> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>>> @@ -26,6 +26,10 @@
>>>
>>>  };
>>>
>>> + {
>>> +   clocks = <>;
>>> +};
>>
>> Can we consider making this property a standard property by the kernel
>> upstream? How does the kernel CLINT timer driver determine its running
>> frequency?
>
> Currently it gets it from /cpus/timebase-frequency.

 What's your comment on this? I think this should go upstream to the
 standard bindings.
>>>
>>> My apologies for delay. Too many mailing list to track.
>>>
>>> I think "clocks" should be an optional DT property for CLINT driver (both
>>> Linux and U-Boot). If "clocks" is not available then we should fallback to
>>> "/cpus/timebase-frequency"
>>>
>>
>> Agreed. The question is whether this should be mentioned in the DT
>> bindings doc in the kernel tree?
> 
> Yes, the "clocks" DT property should be updated in kernel DT bindings doc
> and kernel CLINT driver should also prefer "clocks" DT property when 
> available.
> 
> Regards,
> Anup

Should clock-frequency be used as well, or should that be left for 
timebase-frequency?

--Sean


Re: SquashFS not compiling due to missing __udivdi3 and __umoddi3

2020-09-03 Thread Mauro Condarelli
Small update, see below.

On 9/3/20 10:41 AM, Mauro Condarelli wrote:
> Hi,
> enabling squashfs on my target (vocore2) result in multiple errors:
>
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_calc_n_blks':
>> fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x44): undefined reference to 
>> `__umoddi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x98): undefined reference to 
>> `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_frag_lookup':
>> fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x74): undefined reference to 
>> `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x1b0): undefined reference to 
>> `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_opendir':
>> (.text.sqfs_opendir+0xbc): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_opendir+0x178): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o:(.text.sqfs_read+0x324): more undefined references to 
>> `__udivdi3' follow
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_read':
>> (.text.sqfs_read+0x348): undefined reference to `__umoddi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x388): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x5bc): undefined reference to `__umoddi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x600): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x64c): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_inode_size':
>> (.text.sqfs_inode_size+0x140): undefined reference to `__udivdi3'
>> make[2]: *** [Makefile:1753: u-boot] Error 1
>> make[1]: *** [package/pkg-generic.mk:269: 
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built]
>>  Error 2
>> make: *** [Makefile:23: _all] Error 2
> Following some advice on IRC (I can be contacted there as "mcon")
> I tried to fix issue by explicit calling `lldiv()` (full patch below).
> Fix allows full compilation, and is also somewhat working:
> Directory list works, file load does not :(
>
>> => ls mmc 0:6 /boot    
>>     0   not_mounted
>>   2512916   uImage
>>
>> 2 file(s), 0 dir(s)
>>
>> => load mmc 0:6 8500 /boot/uImage
>> Failed to load '/boot/uImage'
After load failure also dir listing becomes non-functional.
I didn't find any way to cure problem without full reboot.
I have no idea how to debug this.

=> ls mmc 0:6 /boot
    0   not_mounted
  2512916   uImage

2 file(s), 0 dir(s)

=> ls mmc 0:6 /root
   26   .profile
    .ssh/
  673   is_ssh3
 1251   kmsgd
    65536   master.bin
   77   persist_data.lst
  451   public.pem
 1186   termsize
 1675   update
 2853   verkey
 2336   wifi.py

10 file(s), 1 dir(s)

=> load mmc 0:6 8500 /root/persist_data.lst
Failed to load '/root/persist_data.lst'
=> ls mmc 0:6 /root   
=>

> Here I have two questions:
> 1) can someone check my patch end tell me where I goofed?
> 2) is this supposedly the right way to fix? One other suggestion I had
> on IRC is to simply implement __udivdi3/__umoddi3 in my architecture
> (i.e.: u-boot/arch/mips/lib), but that doesn't seem like what has been
> done in other places. I would like to provide an upstreamable patch.
>
>
> ==8<--- Here comes the (tentative) patch==
> From cfd07aac0aa00345df1a0f2fac04ee549c78f87a Mon Sep 17 00:00:00 2001
> From: Mauro Condarelli 
> Date: Thu, 3 Sep 2020 08:37:58 +0200
> Subject: [PATCH 4/4] Fix missing __udivdi3 in SquashFS implementation.
>
> Signed-off-by: Mauro Condarelli 
> ---
>  fs/squashfs/sqfs.c   | 27 ---
>  fs/squashfs/sqfs_inode.c | 11 +--
>  2 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> index f67f7c4a40..12115b6baa 100644
> --- a/fs/squashfs/sqfs.c
> +++ b/fs/squashfs/sqfs.c
> @@ -23,6 +23,12 @@
>  #include "sqfs_filesystem.h"
>  #include 

[PATCH] spl: Kconfig: Record proper dependency for SPL_ATF

2020-09-03 Thread Michal Simek
ATF support was all the time based on FIT image support but this dependency
is not recorded anywhere.
For !SPL_FIT && SPL_ATF there is compilation error:
common/spl/spl.c: In function 'board_init_r':
common/spl/spl.c:689:26: error: 'struct spl_image_info' has no member named 
'fdt_addr'
  689 |   spl_fixup_fdt(spl_image.fdt_addr);

Signed-off-by: Michal Simek 
---

 common/spl/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index af8255a8d6ab..a7fabda969d4 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1271,7 +1271,7 @@ config SPL_YMODEM_SUPPORT
 
 config SPL_ATF
bool "Support ARM Trusted Firmware"
-   depends on ARM64
+   depends on ARM64 && SPL_FIT
help
  ATF(ARM Trusted Firmware) is a component for ARM AArch64 which
  is loaded by SPL (which is considered as BL2 in ATF terminology).
-- 
2.28.0



[PATCH v2 2/2] armv8: lx2162aqds: Add support for LX2162AQDS platform

2020-09-03 Thread meenakshi . aggarwal
From: Meenakshi Aggarwal 

This patch add base support for LX2162AQDS board.
LX2162AQDS board supports LX2162A family SoCs.
This patch add basic support of platform.

Signed-off-by: Ioana Ciornei 
Signed-off-by: Zhao Qiang 
Signed-off-by: hui.song 
Signed-off-by: Manish Tomar 
Signed-off-by: Vikas Singh 
Signed-off-by: Meenakshi Aggarwal 
---
 arch/arm/Kconfig   |  12 +
 arch/arm/dts/Makefile  |   6 +-
 arch/arm/dts/fsl-lx2160a-qds.dts   |   3 -
 arch/arm/dts/fsl-lx2160a-qds.dtsi  |  22 +-
 arch/arm/dts/fsl-lx2162a-qds-17-x.dts  |  17 +
 arch/arm/dts/fsl-lx2162a-qds-18-x.dts  |  17 +
 arch/arm/dts/fsl-lx2162a-qds-20-x.dts  |  17 +
 arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi   |  58 ++
 arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi   |  61 ++
 arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi   |  26 +
 arch/arm/dts/fsl-lx2162a-qds.dts   |  34 +
 board/freescale/common/vid.c   |   3 +-
 board/freescale/lx2160a/Kconfig|  16 +
 board/freescale/lx2160a/MAINTAINERS|  10 +
 board/freescale/lx2160a/Makefile   |   1 +
 board/freescale/lx2160a/README | 132 
 board/freescale/lx2160a/eth_lx2162aqds.c   | 974 +
 board/freescale/lx2160a/lx2160a.c  |  42 +-
 configs/lx2162aqds_tfa_SECURE_BOOT_defconfig   |  97 +++
 configs/lx2162aqds_tfa_defconfig   |  95 +++
 configs/lx2162aqds_tfa_verified_boot_defconfig | 102 +++
 include/configs/lx2160a_common.h   |   2 +
 include/configs/lx2162aqds.h   | 169 +
 23 files changed, 1890 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-17-x.dts
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-18-x.dts
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-20-x.dts
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds.dts
 create mode 100644 board/freescale/lx2160a/eth_lx2162aqds.c
 create mode 100644 configs/lx2162aqds_tfa_SECURE_BOOT_defconfig
 create mode 100644 configs/lx2162aqds_tfa_defconfig
 create mode 100644 configs/lx2162aqds_tfa_verified_boot_defconfig
 create mode 100644 include/configs/lx2162aqds.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 80702c2..258babb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1321,6 +1321,18 @@ config TARGET_LX2160AQDS
  is a high-performance development platform that supports the
  QorIQ LX2160A/LX2120A/LX2080A Layerscape Architecture processor.
 
+config TARGET_LX2162AQDS
+   bool "Support lx2162aqds"
+   select ARCH_LX2162A
+   select ARCH_MISC_INIT
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select ARCH_SUPPORT_TFABOOT
+   select BOARD_LATE_INIT
+   help
+ Support for NXP LX2162AQDS platform.
+ The lx2162aqds support is based on LX2160A Layerscape Architecture 
processor.
+
 config TARGET_HIKEY
bool "Support HiKey 96boards Consumer Edition Platform"
select ARM64
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f8f5294..a34a56e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -409,7 +409,11 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-lx2160a-qds-19-x-x.dtb \
fsl-lx2160a-qds-19-11-x.dtb \
fsl-lx2160a-qds-20-x-x.dtb \
-   fsl-lx2160a-qds-20-11-x.dtb
+   fsl-lx2160a-qds-20-11-x.dtb \
+   fsl-lx2162a-qds.dtb\
+   fsl-lx2162a-qds-17-x.dtb\
+   fsl-lx2162a-qds-18-x.dtb\
+   fsl-lx2162a-qds-20-x.dtb
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb \
diff --git a/arch/arm/dts/fsl-lx2160a-qds.dts b/arch/arm/dts/fsl-lx2160a-qds.dts
index e0f5d5e..332c778 100644
--- a/arch/arm/dts/fsl-lx2160a-qds.dts
+++ b/arch/arm/dts/fsl-lx2160a-qds.dts
@@ -13,7 +13,4 @@
 / {
model = "NXP Layerscape LX2160AQDS Board";
compatible = "fsl,lx2160aqds", "fsl,lx2160a";
-   aliases {
-   spi0 = 
-   };
 };
diff --git a/arch/arm/dts/fsl-lx2160a-qds.dtsi 
b/arch/arm/dts/fsl-lx2160a-qds.dtsi
index 96c9800..288607c 100644
--- a/arch/arm/dts/fsl-lx2160a-qds.dtsi
+++ b/arch/arm/dts/fsl-lx2160a-qds.dtsi
@@ -2,12 +2,18 @@
 /*
  * NXP LX2160AQDS common device tree source
  *
- * Copyright 2018-2019 NXP
+ * Copyright 2018-2020 NXP
  *
  */
 
 #include "fsl-lx2160a.dtsi"
 
+/ {
+   aliases {
+   spi0 = 
+   };
+};
+
  {
status = "okay";
phy-handle = <_phy1>;
@@ -251,6 +257,20 @@
};
 };
 
+ {
+   status = "okay";
+
+   mt35xu512aba0: flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+  

[PATCH v2 1/2] armv8: lx2162a: Add Soc changes to support LX2162A

2020-09-03 Thread meenakshi . aggarwal
From: Meenakshi Aggarwal 

LX2162 is LX2160 based SoC, it has same die as of LX2160
with different packaging.

LX2162A support 64-bit 2.9GT/s DDR4 memory, i2c, micro-click module,
microSD card, eMMC support, serial console, qspi nor flash, qsgmii,
sgmii, 25g, 40g, 50g network interface, one usb 3.0 and serdes
interface to support three PCIe gen3 interface.

Signed-off-by: Meenakshi Aggarwal 
---
 arch/arm/cpu/armv8/Kconfig |  2 +-
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  | 39 +--
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |  2 +-
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  9 ++--
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   | 58 ++
 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  8 +--
 arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c | 19 ++-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 10 ++--
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  6 +--
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  4 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  | 12 ++---
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |  7 ++-
 .../asm/arch-fsl-layerscape/stream_id_lsch3.h  | 10 ++--
 drivers/ddr/fsl/Kconfig|  1 +
 drivers/net/fsl-mc/Kconfig |  4 +-
 drivers/net/ldpaa_eth/Makefile |  1 +
 drivers/pci/Kconfig|  4 +-
 drivers/pci/pcie_layerscape_ep.c   |  4 +-
 drivers/pci/pcie_layerscape_fixup_common.c |  7 ++-
 19 files changed, 166 insertions(+), 41 deletions(-)

diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 3655990..f247441 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -115,7 +115,7 @@ config PSCI_RESET
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
   !TARGET_LS1046AFRWY && \
   !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \
-  !TARGET_LX2160AQDS && \
+  !TARGET_LX2160AQDS && !TARGET_LX2162AQDS && \
   !ARCH_UNIPHIER && !TARGET_S32V234EVB
help
  Most armv8 systems have PSCI support enabled in EL3, either through
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index be51b7d..4d46587 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -208,6 +208,35 @@ config ARCH_LS2080A
imply DISTRO_DEFAULTS
imply PANIC_HANG
 
+config ARCH_LX2162A
+   bool
+   select ARMV8_SET_SMPEN
+   select FSL_LSCH3
+   select NXP_LSCH3_2
+   select SYS_HAS_SERDES
+   select SYS_FSL_SRDS_1
+   select SYS_FSL_SRDS_2
+   select SYS_FSL_DDR
+   select SYS_FSL_DDR_LE
+   select SYS_FSL_DDR_VER_50
+   select SYS_FSL_EC1
+   select SYS_FSL_EC2
+   select SYS_FSL_ERRATUM_A050106
+   select SYS_FSL_HAS_RGMII
+   select SYS_FSL_HAS_SEC
+   select SYS_FSL_HAS_CCN508
+   select SYS_FSL_HAS_DDR4
+   select SYS_FSL_SEC_COMPAT_5
+   select SYS_FSL_SEC_LE
+   select ARCH_EARLY_INIT_R
+   select BOARD_EARLY_INIT_F
+   select SYS_I2C_MXC
+   select RESV_RAM if GIC_V3_ITS
+   imply DISTRO_DEFAULTS
+   imply PANIC_HANG
+   imply SCSI
+   imply SCSI_AHCI
+
 config ARCH_LX2160A
bool
select ARMV8_SET_SMPEN
@@ -345,7 +374,7 @@ config SYS_FSL_ERRATUM_A050106
help
  USB3.0 Receiver needs to enable fixed equalization
  for each of PHY instances in an SOC. This is similar
- to erratum A-009007, but this one is for LX2160A,
+ to erratum A-009007, but this one is for LX2160A and LX2162A,
  and the register value is different.
 
 config SYS_FSL_ERRATUM_A010315
@@ -362,6 +391,7 @@ config MAX_CPUS
default 16 if ARCH_LS2080A
default 8 if ARCH_LS1088A
default 16 if ARCH_LX2160A
+   default 16 if ARCH_LX2162A
default 1
help
  Set this number to the maximum number of possible CPUs in the SoC.
@@ -491,6 +521,7 @@ config SYS_FSL_DUART_CLK_DIV
int "DUART clock divider"
default 1 if ARCH_LS1043A
default 4 if ARCH_LX2160A
+   default 4 if ARCH_LX2162A
default 2
help
  This is the divider that is used to derive DUART clock from Platform
@@ -502,6 +533,7 @@ config SYS_FSL_I2C_CLK_DIV
default 4 if ARCH_LS1012A
default 4 if ARCH_LS1028A
default 8 if ARCH_LX2160A
+   default 8 if ARCH_LX2162A
default 8 if ARCH_LS1088A
default 2
help
@@ -514,6 +546,7 @@ config SYS_FSL_IFC_CLK_DIV
default 4 if ARCH_LS1012A
default 4 if ARCH_LS1028A
default 8 if ARCH_LX2160A
+   default 8 if ARCH_LX2162A
default 8 if ARCH_LS1088A
default 2
help
@@ -560,14 +593,14 @@ config SYS_FSL_EC1

[PATCH v2 0/2] Add support for LX2162AQDS board

2020-09-03 Thread meenakshi . aggarwal
From: Meenakshi Aggarwal 

This patch set add support for LX2162AQDS board.
LX2162A is a variant of LX2160A.

---
Changes:
v2:
- Add Separate ARCH for LX2162A SoC
- Updated ReadMe of SoC and board

Meenakshi Aggarwal (2):
  armv8: lx2162a: Add Soc changes to support LX2162A
  armv8: lx2162aqds: Add support for LX2162AQDS platform

 arch/arm/Kconfig   |  12 +
 arch/arm/cpu/armv8/Kconfig |   2 +-
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  39 +-
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   2 +-
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   9 +-
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   |  58 ++
 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|   8 +-
 arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c |  19 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|  10 +-
 arch/arm/dts/Makefile  |   6 +-
 arch/arm/dts/fsl-lx2160a-qds.dts   |   3 -
 arch/arm/dts/fsl-lx2160a-qds.dtsi  |  22 +-
 arch/arm/dts/fsl-lx2162a-qds-17-x.dts  |  17 +
 arch/arm/dts/fsl-lx2162a-qds-18-x.dts  |  17 +
 arch/arm/dts/fsl-lx2162a-qds-20-x.dts  |  17 +
 arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi   |  58 ++
 arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi   |  61 ++
 arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi   |  26 +
 arch/arm/dts/fsl-lx2162a-qds.dts   |  34 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |   6 +-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  12 +-
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   7 +-
 .../asm/arch-fsl-layerscape/stream_id_lsch3.h  |  10 +-
 board/freescale/common/vid.c   |   3 +-
 board/freescale/lx2160a/Kconfig|  16 +
 board/freescale/lx2160a/MAINTAINERS|  10 +
 board/freescale/lx2160a/Makefile   |   1 +
 board/freescale/lx2160a/README | 132 +++
 board/freescale/lx2160a/eth_lx2162aqds.c   | 974 +
 board/freescale/lx2160a/lx2160a.c  |  42 +-
 configs/lx2162aqds_tfa_SECURE_BOOT_defconfig   |  97 ++
 configs/lx2162aqds_tfa_defconfig   |  95 ++
 configs/lx2162aqds_tfa_verified_boot_defconfig | 102 +++
 drivers/ddr/fsl/Kconfig|   1 +
 drivers/net/fsl-mc/Kconfig |   4 +-
 drivers/net/ldpaa_eth/Makefile |   1 +
 drivers/pci/Kconfig|   4 +-
 drivers/pci/pcie_layerscape_ep.c   |   4 +-
 drivers/pci/pcie_layerscape_fixup_common.c |   7 +-
 include/configs/lx2160a_common.h   |   2 +
 include/configs/lx2162aqds.h   | 169 
 42 files changed, 2056 insertions(+), 67 deletions(-)
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-17-x.dts
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-18-x.dts
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-20-x.dts
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi
 create mode 100644 arch/arm/dts/fsl-lx2162a-qds.dts
 create mode 100644 board/freescale/lx2160a/eth_lx2162aqds.c
 create mode 100644 configs/lx2162aqds_tfa_SECURE_BOOT_defconfig
 create mode 100644 configs/lx2162aqds_tfa_defconfig
 create mode 100644 configs/lx2162aqds_tfa_verified_boot_defconfig
 create mode 100644 include/configs/lx2162aqds.h

-- 
2.7.4



SquashFS not compiling due to missing __udivdi3 and __umoddi3

2020-09-03 Thread Mauro Condarelli
Hi,
enabling squashfs on my target (vocore2) result in multiple errors:

> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_calc_n_blks':
> fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x44): undefined reference to 
> `__umoddi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x98): undefined reference to 
> `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_frag_lookup':
> fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x74): undefined reference to 
> `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x1b0): undefined reference to 
> `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_opendir':
> (.text.sqfs_opendir+0xbc): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_opendir+0x178): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o:(.text.sqfs_read+0x324): more undefined references to 
> `__udivdi3' follow
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_read':
> (.text.sqfs_read+0x348): undefined reference to `__umoddi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x388): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x5bc): undefined reference to `__umoddi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x600): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x64c): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_inode_size':
> (.text.sqfs_inode_size+0x140): undefined reference to `__udivdi3'
> make[2]: *** [Makefile:1753: u-boot] Error 1
> make[1]: *** [package/pkg-generic.mk:269: 
> /home/mcon/vocore/__V2__/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built]
>  Error 2
> make: *** [Makefile:23: _all] Error 2

Following some advice on IRC (I can be contacted there as "mcon")
I tried to fix issue by explicit calling `lldiv()` (full patch below).
Fix allows full compilation, and is also somewhat working:
Directory list works, file load does not :(

> => ls mmc 0:6 /boot    
>     0   not_mounted
>   2512916   uImage
>
> 2 file(s), 0 dir(s)
>
> => load mmc 0:6 8500 /boot/uImage
> Failed to load '/boot/uImage'

Here I have two questions:
1) can someone check my patch end tell me where I goofed?
2) is this supposedly the right way to fix? One other suggestion I had
on IRC is to simply implement __udivdi3/__umoddi3 in my architecture
(i.e.: u-boot/arch/mips/lib), but that doesn't seem like what has been
done in other places. I would like to provide an upstreamable patch.


==8<--- Here comes the (tentative) patch==
>From cfd07aac0aa00345df1a0f2fac04ee549c78f87a Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Thu, 3 Sep 2020 08:37:58 +0200
Subject: [PATCH 4/4] Fix missing __udivdi3 in SquashFS implementation.

Signed-off-by: Mauro Condarelli 
---
 fs/squashfs/sqfs.c   | 27 ---
 fs/squashfs/sqfs_inode.c | 11 +--
 2 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index f67f7c4a40..12115b6baa 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -23,6 +23,12 @@
 #include "sqfs_filesystem.h"
 #include "sqfs_utils.h"
 
+#include 
+#ifdef DIV_ROUND_UP
+#undef DIV_ROUND_UP
+#endif
+#define DIV_ROUND_UP(n,d) (lldiv(((n) + (d) - 1), (d)))
+
 static struct squashfs_ctxt ctxt;
 
 static int sqfs_disk_read(__u32 block, __u32 nr_blocks, void *buf)
@@ -85,7 +91,7 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 
*offset)
 u64 start_, table_size;
 
 table_size = le64_to_cpu(end) - le64_to_cpu(start);
-    start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
+    start_ = lldiv(le64_to_cpu(start), ctxt.cur_dev->blksz);
 *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
 
 return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
@@ -109,8 +115,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
 if (inode_fragment_index >= get_unaligned_le32(>fragments))
     return 

Re: [PATCH 0/8] PinePhone automatic device tree selection

2020-09-03 Thread Maxime Ripard
Hi,

On Thu, Sep 03, 2020 at 12:07:08AM -0500, Samuel Holland wrote:
> All,
> 
> This patch series implements a feature to automatically choose the
> right PinePhone device tree by probing the hardware. It then extends
> the functionality to pass the chosen DTB name to the boot command.
> Finally, I add device trees and a defconfig for the PinePhone.
> 
> I'm aware that Andre has concerns about updating the device tree files.
> It would be unfortunate for this to block new hardware support. Since
> the device trees are primarily maintained in the Linux repository, and
> only copied here, I believe compatibility concerns should be directed
> there, not here. In any case, the first 6 patches can be merged
> independently, so I request that they be merged even if patches 7-8 are
> not. I am mainly including the last two patches for ease of testing.

It looks great to me, thanks!

Acked-by: Maxime Ripard 


signature.asc
Description: PGP signature


[GIT PULL] SoCFPGA change for v2020-10-rc4

2020-09-03 Thread Tan, Ley Foon
Hi Tom

Please pull one change for u-boot SoCFPGA.

Regards
Ley Foon


The following changes since commit 7149077353ef4837ab2fcdce5d7e52c5ed4b026a:

  Azure/GitLab: Update to latest Docker container (2020-09-02 09:22:29 -0400)

are available in the Git repository at:

  https://github.com/lftan/u-boot.git for-tom

for you to fetch changes up to 6b6307ed22121a38c5b1a5198e737e78b7135312:

  arm: socfpga: soc64: Check FPGA Config status register before bridge reset 
(2020-09-03 11:26:07 +0800)


Chee Hong Ang (1):
  arm: socfpga: soc64: Check FPGA Config status register before bridge reset

 arch/arm/mach-socfpga/include/mach/misc.h  |  5 +
 .../mach-socfpga/include/mach/system_manager_soc64.h   |  6 +-
 arch/arm/mach-socfpga/misc_s10.c   | 18 ++
 3 files changed, 20 insertions(+), 9 deletions(-)


Re: [PATCH 09/31] clk: ti: refactor mux and divider clock drivers

2020-09-03 Thread Lokesh Vutla



On 25/08/20 2:51 pm, Dario Binacchi wrote:
> The patch removes duplicate routines used by the two drivers.
> 
> Signed-off-by: Dario Binacchi 

Please squash it into previous patches.

Thanks and regards,
Lokesh

> ---
> 
>  drivers/clk/Makefile |  1 +
>  drivers/clk/clk-ti-divider.c | 27 ++-
>  drivers/clk/clk-ti-mux.c | 27 ++-
>  drivers/clk/clk-ti.c | 34 ++
>  drivers/clk/clk-ti.h | 13 +
>  5 files changed, 52 insertions(+), 50 deletions(-)
>  create mode 100644 drivers/clk/clk-ti.c
>  create mode 100644 drivers/clk/clk-ti.h
> 
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 0fcfcc1837..21b1e9c364 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_ARCH_ASPEED) += aspeed/
>  obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
>  obj-$(CONFIG_ARCH_MTMIPS) += mtmips/
>  obj-$(CONFIG_ARCH_MESON) += meson/
> +obj-$(CONFIG_ARCH_OMAP2PLUS) += clk-ti.o
>  obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
>  obj-$(CONFIG_ARCH_SOCFPGA) += altera/
>  obj-$(CONFIG_CLK_AT91) += at91/
> diff --git a/drivers/clk/clk-ti-divider.c b/drivers/clk/clk-ti-divider.c
> index fa9d60a2d5..d16cc30cb7 100644
> --- a/drivers/clk/clk-ti-divider.c
> +++ b/drivers/clk/clk-ti-divider.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include "clk-ti.h"
>  
>  /*
>   * The reverse of DIV_ROUND_UP: The maximum number which
> @@ -36,30 +37,6 @@ struct clk_ti_divider_priv {
>   u16 mask;
>  };
>  
> -static void clk_ti_divider_rmw(u32 val, u32 mask, fdt_addr_t reg)
> -{
> - u32 v;
> -
> - v = readl(reg);
> - v &= ~mask;
> - v |= val;
> - writel(v, reg);
> -}
> -
> -static void clk_ti_divider_latch(fdt_addr_t reg, s8 shift)
> -{
> - u32 latch;
> -
> - if (shift < 0)
> - return;
> -
> - latch = 1 << shift;
> -
> - clk_ti_divider_rmw(latch, latch, reg);
> - clk_ti_divider_rmw(0, latch, reg);
> - readl(reg); /* OCP barrier */
> -}
> -
>  static unsigned int _get_div(const struct clk_div_table *table, ulong flags,
>unsigned int val)
>  {
> @@ -226,7 +203,7 @@ static ulong clk_ti_divider_set_rate(struct clk *clk, 
> ulong rate)
>   v &= ~(priv->mask << priv->shift);
>   v |= val << priv->shift;
>   writel(v, priv->reg);
> - clk_ti_divider_latch(priv->reg, priv->latch);
> + clk_ti_latch(priv->reg, priv->latch);
>  
>   return clk_get_rate(clk);
>  }
> diff --git a/drivers/clk/clk-ti-mux.c b/drivers/clk/clk-ti-mux.c
> index 7e39dd3477..e4b190bbcc 100644
> --- a/drivers/clk/clk-ti-mux.c
> +++ b/drivers/clk/clk-ti-mux.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include "clk-ti.h"
>  
>  struct clk_ti_mux_priv {
>   struct clk_bulk parents;
> @@ -23,30 +24,6 @@ struct clk_ti_mux_priv {
>   s32 latch;
>  };
>  
> -static void clk_ti_mux_rmw(u32 val, u32 mask, fdt_addr_t reg)
> -{
> - u32 v;
> -
> - v = readl(reg);
> - v &= ~mask;
> - v |= val;
> - writel(v, reg);
> -}
> -
> -static void clk_ti_mux_latch(fdt_addr_t reg, s8 shift)
> -{
> - u32 latch;
> -
> - if (shift < 0)
> - return;
> -
> - latch = 1 << shift;
> -
> - clk_ti_mux_rmw(latch, latch, reg);
> - clk_ti_mux_rmw(0, latch, reg);
> - readl(reg); /* OCP barrier */
> -}
> -
>  static struct clk *clk_ti_mux_get_parent_by_index(struct clk_bulk *parents,
> int index)
>  {
> @@ -119,7 +96,7 @@ static int clk_ti_mux_set_parent(struct clk *clk, struct 
> clk *parent)
>  
>   val |= index << priv->shift;
>   writel(val, priv->reg);
> - clk_ti_mux_latch(priv->reg, priv->latch);
> + clk_ti_latch(priv->reg, priv->latch);
>   return 0;
>  }
>  
> diff --git a/drivers/clk/clk-ti.c b/drivers/clk/clk-ti.c
> new file mode 100644
> index 00..594ef75270
> --- /dev/null
> +++ b/drivers/clk/clk-ti.c
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * TI clock utilities
> + *
> + * Copyright (C) 2020 Dario Binacchi 
> + */
> +
> +#include 
> +#include 
> +#include "clk-ti.h"
> +
> +static void clk_ti_rmw(u32 val, u32 mask, fdt_addr_t reg)
> +{
> + u32 v;
> +
> + v = readl(reg);
> + v &= ~mask;
> + v |= val;
> + writel(v, reg);
> +}
> +
> +void clk_ti_latch(fdt_addr_t reg, s8 shift)
> +{
> + u32 latch;
> +
> + if (shift < 0)
> + return;
> +
> + latch = 1 << shift;
> +
> + clk_ti_rmw(latch, latch, reg);
> + clk_ti_rmw(0, latch, reg);
> + readl(reg); /* OCP barrier */
> +}
> diff --git a/drivers/clk/clk-ti.h b/drivers/clk/clk-ti.h
> new file mode 100644
> index 00..601c3823f7
> --- /dev/null
> +++ b/drivers/clk/clk-ti.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * TI clock utilities header
> + *
> + * Copyright (C) 2020 

Re: [PATCH 18/31] misc: am33xx: add control module driver

2020-09-03 Thread Lokesh Vutla



On 25/08/20 2:51 pm, Dario Binacchi wrote:
> The implementation of this driver was needed to bind the device tree
> sub-nodes of the 'clocks' node. In fact, the lack of the compatible
> property in the 'clocks' node does not allow the generic 'syscon' or
> 'simple-bus' drivers linked to the 'scm_conf@0' node to bind the
> 'clocks' node and in turn its sub-nodes.
> The 'scm@21' node is therefore the node closest to the 'clocks' node
> whose driver can bind all the 'clocks' sub-nodes.
> 
> scm: scm@21 {
>   compatible = "ti,am3-scm", "simple-bus";
>   ...
> 
>   scm_conf: scm_conf@0 {
>   compatible = "syscon", "simple-bus";
>   #address-cells = <1>;
>   #size-cells = <1>;
>   ranges = <0 0 0x800>;
> 
>   scm_clocks: clocks {
>   #address-cells = <1>;
>   #size-cells = <0>;
>   };
>   };
> };
> 
> Signed-off-by: Dario Binacchi 
> ---
> 
>  doc/device-tree-bindings/arm/omap,ctrl.txt|  82 ++
>  .../pinctrl/pinctrl-single.txt| 255 ++

This documentation does not belong to this patch.

>  drivers/misc/Kconfig  |   7 +
>  drivers/misc/Makefile |   1 +
>  drivers/misc/ti-am3-scm.c |  90 +++
>  5 files changed, 435 insertions(+)
>  create mode 100644 doc/device-tree-bindings/arm/omap,ctrl.txt
>  create mode 100644 doc/device-tree-bindings/pinctrl/pinctrl-single.txt
>  create mode 100644 drivers/misc/ti-am3-scm.c
> 
> diff --git a/doc/device-tree-bindings/arm/omap,ctrl.txt 
> b/doc/device-tree-bindings/arm/omap,ctrl.txt
> new file mode 100644
> index 00..8efd321cfa
> --- /dev/null
> +++ b/doc/device-tree-bindings/arm/omap,ctrl.txt
> @@ -0,0 +1,82 @@
> +OMAP Control Module bindings
> +
> +Control Module contains miscellaneous features under it based on SoC type.
> +Pincontrol is one common feature, and it has a specialized support
> +described in [1]. Typically some clock nodes are also under control module.
> +Syscon is used to share register level access to drivers external to
> +control module driver itself.
> +
> +See [2] for documentation about clock/clockdomain nodes.
> +
> +[1] doc/device-tree-bindings/pinctrl/pinctrl-single.txt
> +[2] doc/device-tree-bindings/clock/ti,*.txt
> +
> +Required properties:
> +- compatible:Must be one of:
> + "ti,am3-scm"
> + "ti,am4-scm"
> + "ti,dm814-scrm"
> + "ti,dm816-scrm"
> + "ti,omap2-scm"
> + "ti,omap3-scm"
> + "ti,omap4-scm-core"
> + "ti,omap4-scm-padconf-core"
> + "ti,omap4-scm-wkup"
> + "ti,omap4-scm-padconf-wkup"
> + "ti,omap5-scm-core"
> + "ti,omap5-scm-padconf-core"
> + "ti,omap5-scm-wkup-pad-conf"
> + "ti,dra7-scm-core"
> +- reg:   Contains Control Module register address range
> + (base address and length)
> +
> +Optional properties:
> +- clocks:clocks for this module
> +- clockdomains:  clockdomains for this module
> +
> +Examples:
> +
> +scm: scm@2000 {
> + compatible = "ti,omap3-scm", "simple-bus";
> + reg = <0x2000 0x2000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x2000 0x2000>;
> +
> + omap3_pmx_core: pinmux@30 {
> + compatible = "ti,omap3-padconf",
> +  "pinctrl-single";
> + reg = <0x30 0x230>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + pinctrl-single,register-width = <16>;
> + pinctrl-single,function-mask = <0xff1f>;
> + };
> +
> + scm_conf: scm_conf@270 {
> + compatible = "syscon";
> + reg = <0x270 0x330>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + scm_clocks: clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + scm_clockdomains: clockdomains {
> + };
> +}
> +
> +_clocks {
> + mcbsp5_mux_fck: mcbsp5_mux_fck {
> + #clock-cells = <0>;
> + compatible = "ti,composite-mux-clock";
> + clocks = <_96m_fck>, <_clks>;
> + ti,bit-shift = <4>;
> + reg = <0x02d8>;
> + };
> +};

[...snip...]


> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index b67e906a76..9e8b676637 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -500,4 +500,11 @@ config ESM_PMIC
> Support ESM (Error Signal Monitor) on PMIC devices. ESM is used
> typically to reboot the board in error condition.
>  
> +config TI_AM3_SCM
> + bool "AM33XX specific control module support (SCM)"
> + depends on ARCH_OMAP2PLUS
> + help
> + 

[PATCH v2 3/3] sunxi: Add support for including SCP firmware

2020-09-03 Thread Samuel Holland
Allwinner sun50i SoCs contain an OpenRISC 1000 CPU that functions as a
System Control Processor, or SCP. ARM Trusted Firmware (ATF)
communicates with the SCP over SCPI to implement the PSCI system suspend
and shutdown functionality. Currently, SCP firmware is optional; the
system will boot and run without it, but system suspend will be
unavailable.

Since all communication with the SCP is mediated by ATF, the only thing
U-Boot needs to do is load the firmware into SRAM. The SCP firmware
occupies the last 16KiB of SRAM A2, immediately following ATF.

Signed-off-by: Samuel Holland 
---

Changes since v1:
  - None

---
 board/sunxi/README.sunxi64 | 43 --
 board/sunxi/mksunxi_fit_atf.sh | 23 +++---
 2 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64
index 258921af22d..9a67e5301eb 100644
--- a/board/sunxi/README.sunxi64
+++ b/board/sunxi/README.sunxi64
@@ -14,8 +14,12 @@ Quick Start / Overview
 - Build the ARM Trusted Firmware binary (see "ARM Trusted Firmware (ATF)" 
below)
   $ cd /src/arm-trusted-firmware
   $ make PLAT=sun50i_a64 DEBUG=1 bl31
+- Build the SCP firmware binary (see "SCP firmware (Crust)" below)
+  $ cd /src/crust
+  $ make pine64_plus_defconfig && make -j5 scp
 - Build U-Boot (see "SPL/U-Boot" below)
   $ export BL31=/path/to/bl31.bin
+  $ export SCP=/src/crust/build/scp/scp.bin
   $ make pine64_plus_defconfig && make -j5
 - Transfer to an uSD card (see "microSD card" below)
   $ dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1
@@ -24,13 +28,17 @@ Quick Start / Overview
 Building the firmware
 =
 
-The Allwinner A64/H5 firmware consists of three parts: U-Boot's SPL, an
-ARM Trusted Firmware (ATF) build and the U-Boot proper.
-The SPL will load both ATF and U-Boot proper along with the right device
-tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will
-drop into the U-Boot proper (in EL2).
-As the ATF binary will become part of the U-Boot image file, you will need
-to build it first.
+The Allwinner A64/H5/H6 firmware consists of several parts: U-Boot's SPL,
+ARM Trusted Firmware (ATF), optional System Control Processor (SCP) firmware
+(e.g. Crust), and the U-Boot proper.
+
+The SPL will load all of the other firmware binaries into RAM, along with the
+right device tree blob (.dtb), and will pass execution to ATF (in EL3). If SCP
+firmware was loaded, ATF will power on the SCP and wait for it to boot.
+ATF will then drop into U-Boot proper (in EL2).
+
+As the ATF binary and SCP firmware will become part of the U-Boot image file,
+you will need to build them first.
 
  ARM Trusted Firmware (ATF)
 
@@ -53,6 +61,27 @@ As sometimes the ATF build process is a bit picky about the 
toolchain used,
 or if you can't be bothered with building ATF, there are known working
 binaries in the firmware repository[3], purely for convenience reasons.
 
+ SCP firmware (Crust)
+--
+SCP firmware is responsible for implementing system suspend/resume, and (on
+boards without a PMIC) soft poweroff/on. ATF contains fallback code for CPU
+power control, so SCP firmware is optional if you don't need either of these
+features. It runs on the AR100, with is an or1k CPU, not ARM, so it needs a
+different cross toolchain.
+
+There is one SCP firmware implementation currently available, Crust:
+$ git clone https://github.com/crust-firmware/crust
+$ cd crust
+$ export CROSS_COMPILE=or1k-linux-musl-
+$ make pine64_plus_defconfig
+$ make scp
+
+The same configuration generally works on any board with the same SoC (A64, H5,
+or H6), so if there is no config for your board, use one for a similar board.
+
+Like for ATF, U-Boot finds the SCP firmware binary via an environment variable:
+$ export SCP=/src/crust/build/scp/scp.bin
+
  SPL/U-Boot
 
 Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
index 4dfd22db781..07a2e619ee4 100755
--- a/board/sunxi/mksunxi_fit_atf.sh
+++ b/board/sunxi/mksunxi_fit_atf.sh
@@ -1,11 +1,12 @@
 #!/bin/sh
 #
-# script to generate FIT image source for 64-bit sunxi boards with
-# ARM Trusted Firmware and multiple device trees (given on the command line)
+# script to generate FIT image source for 64-bit sunxi boards with ARM Trusted
+# Firmware, SCP firmware, and multiple device trees (given on the command line)
 #
 # usage: $0  [ [&2
@@ -13,10 +14,18 @@ if [ ! -f $BL31 ]; then
BL31=/dev/null
 fi
 
+if [ ! -f $SCP ]; then
+   echo "WARNING: SCP firmware file $SCP NOT found, system suspend will be 
unavailable" >&2
+   echo "Please read the section on SCP firmware in 
board/sunxi/README.sunxi64" >&2
+   SCP=/dev/null
+fi
+
 if grep -q "^CONFIG_MACH_SUN50I_H6=y" .config; then
BL31_ADDR=0x104000
+   SCP_ADDR=0x114000
 else
BL31_ADDR=0x44000
+ 

[PATCH v2 2/3] mksunxi_fit_atf.sh: Update FIT component descriptions

2020-09-03 Thread Samuel Holland
Since commit d879616e9e64 ("spl: fit: simplify logic for FDT loading for
non-OS boots"), the SPL looks at the "os" properties of FIT images to
determine where to append the FDT.

The "os" property of the "firmware" image also determines how to execute
the next stage of the boot process, as in 1d3790905d9c ("spl: atf:
introduce spl_invoke_atf and make bl31_entry private").

To support this additional functionality, and to properly model the boot
process, where ATF runs before U-Boot, add the "os" properties and swap
the firmware/loadable images in the FIT image.

Acked-by: Patrick Wildt 
Signed-off-by: Samuel Holland 
---

Changes since v1:
  - Collect tags

---
 board/sunxi/mksunxi_fit_atf.sh | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
index 88ad7197470..4dfd22db781 100755
--- a/board/sunxi/mksunxi_fit_atf.sh
+++ b/board/sunxi/mksunxi_fit_atf.sh
@@ -31,6 +31,7 @@ cat << __HEADER_EOF
description = "U-Boot (64-bit)";
data = /incbin/("u-boot-nodtb.bin");
type = "standalone";
+   os = "u-boot";
arch = "arm64";
compression = "none";
load = <0x4a00>;
@@ -39,6 +40,7 @@ cat << __HEADER_EOF
description = "ARM Trusted Firmware";
data = /incbin/("$BL31");
type = "firmware";
+   os = "arm-trusted-firmware";
arch = "arm64";
compression = "none";
load = <$BL31_ADDR>;
@@ -73,8 +75,8 @@ do
cat << __CONF_SECTION_EOF
config_$cnt {
description = "$(basename $dtname .dtb)";
-   firmware = "uboot";
-   loadables = "atf";
+   firmware = "atf";
+   loadables = "uboot";
fdt = "fdt_$cnt";
};
 __CONF_SECTION_EOF
-- 
2.26.2



[PATCH v2 1/3] spl: fit: Minimally parse OS properties with FIT_IMAGE_TINY

2020-09-03 Thread Samuel Holland
Some boards, specifically 64-bit Allwinner boards (sun50i), are
extremely limited on SPL size. One strategy that was used to make space
was to remove the FIT "os" property parsing code, because it uses a
rather large lookup table.

However, this forces the legacy FIT parsing code path, which requires
the "firmware" entry in the FIT to reference the U-Boot binary, even if
U-Boot is not the next binary in the boot sequence (for example, on
sun50i boards, ATF is run first).

This prevents the same FIT image from being used with a SPL with
CONFIG_SPL_FIT_IMAGE_TINY=n and CONFIG_SPL_ATF=y, because the boot
method selection code looks at `spl_image.os`, which is only set from
the "firmware" entry's "os" property.

To be able to use CONFIG_SPL_ATF=y, the "firmware" entry in the FIT
must be ATF, and U-Boot must be a loadable. For this to work, we need to
parse the "os" property just enough to tell U-Boot from other images, so
we can find it in the loadables list to append the FDT, and so we don't
try to append the FDT to ATF (which could clobber adjacent firmware).

So add the minimal code necessary to distinguish U-Boot/non-U-Boot
loadables with CONFIG_SPL_FIT_IMAGE_TINY=y. This adds about 300 bytes,
much less than the 7400 bytes added by CONFIG_SPL_FIT_IMAGE_TINY=n.

Acked-by: Patrick Wildt 
Signed-off-by: Samuel Holland 
---

Changes since v1:
  - Collect tags

---

 common/spl/Kconfig   |  4 +---
 common/spl/spl_fit.c | 17 -
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index af8255a8d6a..041b47244bd 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -465,9 +465,7 @@ config SPL_FIT_IMAGE_TINY
  Enable this to reduce the size of the FIT image loading code
  in SPL, if space for the SPL binary is very tight.
 
- This removes the detection of image types (which forces the
- first image to be treated as having a U-Boot style calling
- convention) and skips the recording of each loaded payload
+ This skips the recording of each loaded payload
  (i.e. loadable) into the FDT (modifying the loaded FDT to
  ensure this information is available to the next image
  invoked).
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 365104fe028..a31ab6c5992 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -466,7 +466,22 @@ static int spl_fit_record_loadable(const void *fit, int 
images, int index,
 static int spl_fit_image_get_os(const void *fit, int noffset, uint8_t *os)
 {
 #if CONFIG_IS_ENABLED(FIT_IMAGE_TINY) && !defined(CONFIG_SPL_OS_BOOT)
-   return -ENOTSUPP;
+   const char *name = fdt_getprop(fit, noffset, FIT_OS_PROP, NULL);
+
+   if (!name)
+   return -ENOENT;
+
+   /*
+* We don't care what the type of the image actually is,
+* only whether or not it is U-Boot. This saves some
+* space by omitting the large table of OS types.
+*/
+   if (!strcmp(name, "u-boot"))
+   *os = IH_OS_U_BOOT;
+   else
+   *os = IH_OS_INVALID;
+
+   return 0;
 #else
return fit_image_get_os(fit, noffset, os);
 #endif
-- 
2.26.2