[PATCH] ARM: MediaTek: amend IC description for MediaTek MT8512
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
