[PATCH] efi: add comment for efi_system_table and efi_configuration_table

2021-11-11 Thread Masahisa Kojima
This commit adds the comment for efi_system_table and
efi_configuration_table structure.

Signed-off-by: Masahisa Kojima 
---
 include/efi_api.h | 32 
 1 file changed, 32 insertions(+)

diff --git a/include/efi_api.h b/include/efi_api.h
index 0accad08c8..78a6412116 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -417,6 +417,15 @@ struct efi_runtime_services {
EFI_GUID(0x1e2ed096, 0x30e2, 0x4254, 0xbd, \
 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
 
+/**
+ * struct efi_configuration_table - EFI Configuration Table
+ *
+ * This table contains a set of GUID/pointer pairs.
+ * The EFI Configuration Table may contain at most one instance of each table 
type.
+ *
+ * @guid:  GUID that uniquely identifies the system configuration 
table
+ * @table: A pointer to the table associated with guid
+ */
 struct efi_configuration_table {
efi_guid_t guid;
void *table;
@@ -424,6 +433,29 @@ struct efi_configuration_table {
 
 #define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
 
+/**
+ * struct efi_system_table - EFI System Table
+ *
+ * EFI System Table contains pointers to the runtime and boot services tables.
+ *
+ * @hdr:   The table header for the EFI System Table
+ * @fw_vendor: A pointer to a null terminated string that identifies 
the vendor
+ * that produces the system firmware
+ * @fw_version:The revision of the system firmware
+ * @con_in_handle: The handle for the active console input device
+ * @con_in:A pointer to the EFI_SIMPLE_TEXT_INPUT_PROTOCOL 
interface
+ * that is associated with con_in_handle
+ * @con_out_handle:The handle for the active console output device
+ * @con_out:   A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL 
interface
+ * that is associated with con_out_handle
+ * @stderr_handle: The handle for the active standard error console device
+ * @std_err:   A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL 
interface
+ * that is associated with stderr_handle
+ * @runtime:   A pointer to the EFI Runtime Services Table
+ * @boottime:  A pointer to the EFI Boot Services Table
+ * @nr_tables: The number of system configuration tables
+ * @tables:A pointer to the system configuration tables
+ */
 struct efi_system_table {
struct efi_table_hdr hdr;
u16 *fw_vendor;   /* physical addr of wchar_t vendor string */
-- 
2.17.1



Re: [RFC 3/3] cmd: efidebug: handle booting from removable media

2021-11-11 Thread AKASHI Takahiro
On Wed, Nov 10, 2021 at 10:17:50AM +0100, Heinrich Schuchardt wrote:
> On 11/10/21 09:11, Heinrich Schuchardt wrote:
> > 
> > 
> > On 11/10/21 07:24, AKASHI Takahiro wrote:
> > > On Tue, Nov 09, 2021 at 10:50:37AM +0100, Heinrich Schuchardt wrote:
> > > > On 11/9/21 02:32, AKASHI Takahiro wrote:
> > > > > Support for booting from removable media is now added to UEFI boot
> > > > > manager. Here we should modify efidebug command in order to define
> > > > > a proper "Boot" variable.
> > > > > 
> > > > > With this patch applied, you will be able to specify the boot order,
> > > > > usb and scsi:
> > > > 
> > > > I guess for a removable device this should work even if the
> > > > device is not
> > > > present. But currently:
> > > > 
> > > > => efidebug boot add -b 1000 USB_present usb 0:1 EFI/BOOT/BOOTARM.EFI
> > > > => efidebug boot add -b 1000 USB_not_present usb 1:1
> > > > EFI/BOOT/BOOTARM.EFI
> > > > Cannot create device path for "usb 1:1"
> > > 
> > > # In the second, I don't expect you to specify the file path,
> > > # "EFI/BOOT/BOOTARM.EFI", for removable media support.
> > > 
> > > Yes, I have been aware of this issue but it is not this-patch specific
> > > but an existing issue as you clearly mentioned above.
> > > 
> > > > A media device path like:
> > > > 
> > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0x0c449046,0x800,0x800)
> > > > 
> > > > 
> > > > is not very helpful because the next device that you insert may have a
> > > > different location of the ESP partition.
> > > > 
> > > > I think you should store
> > > > 
> > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)
> > > > 
> > > 
> > > Apparently it is promising but actually not because
> > > "UsbClass(0x781,0x5571,0x0,0x0,0x0)" contains Vendor ID and
> > > Product ID which can only be retrieved from a real device attached
> > > to the board.
> > 
> > 0x781,0x5571 relates to
> > Vendor: SanDisk Corp.
> > Device: Cruzer Fit
> > 
> > This is how Linux sees my OrangePi PC:
> > 
> > $ lsusb
> > Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 006 Device 002: ID 0781:5571 SanDisk Corp. Cruzer Fit
> > Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > 
> > The bus numbering seems not to be stable:
> > 
> > $ lsusb
> > Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 005 Device 002: ID 0781:5571 SanDisk Corp. Cruzer Fit
> > Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > 
> > 
> > And this is in U-Boot:
> > 
> > usb   0  [ + ]   ehci_generic  |   |-- usb@1c1a000
> > usb_hub   0  [ + ]   usb_hub   |   |   `-- usb_hub
> > usb   1  [ + ]   ohci_generic  |   |-- usb@1c1a400
> > usb_hub   1  [ + ]   usb_hub   |   |   `-- usb_hub
> > usb   2  [ + ]   ehci_generic  |   |-- usb@1c1b000
> > usb_hub   2  [ + ]   usb_hub   |   |   `-- usb_hub
> > usb   3  [ + ]   ohci_generic  |   |-- usb@1c1b400
> > usb_hub   3  [ + ]   usb_hub   |   |   `-- usb_hub
> > usb   4  [ + ]   ehci_generic  |   |-- usb@1c1c000
> > usb_hub   4  [ + ]   usb_hub   |   |   `-- usb_hub
> > usb_mass_s    0  [ + ]   usb_mass_storage  |  
> > |   `-- usb_mass_storage
> > blk   1  [   ]   usb_storage_blk  
> > |   |   `-- usb_mass_storage.lun0
> > usb   5  [ + ]   ohci_generic  |   |-- usb@1c1c400
> > usb_hub   5  [ + ]   usb_hub   |   |   `-- usb_hub
> > usb   6  [ + ]   ehci_generic  |   |-- usb@1c1d000
> > usb_hub   6  [ + ]   usb_hub   |   |   `-- usb_hub
> > usb   7  [ + ]   ohci_generic  |   |-- usb@1c1d400
> > usb_hub   7  [ + ]   usb_hub   |   |   `-- usb_hub
> > 
> > The location where a USB is plugged is identified by the port of the USB
> > hub it is conne

Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-11 Thread Bin Meng
On Thu, Nov 11, 2021 at 9:17 PM  wrote:
>
> > I agree with Bin here. You shouldn't introduce a new compatible just for
> > u-boot. If you need one, please to it first in linux and get an ACK there.
> > Or at least there should be patches for it pending in linux and it should
> > be likely, that they will be accepted.
> >
> > Please work towards having one binding for u-boot and linux.
> >
> > -michael
>
> I think both Michael and Bin are right, but that maybe this has gone circular.
>
> IIRC, Linux *doesn't need* any extra bindings because its driver already
> supports 64-bit DMA.
>
> Padmarao's original patch added equivalent 64-bit functionality to the
> driver in U-Boot, but this was rejected.
>

I am not sure why it was rejected. Is that because it breaks some
other platforms?

> Instead I think the suggestion was to add a device-tree binding to choose 32 
> or
> 64-bit DMA...  however, there is no reasonably way of upstreaming this into
> the Linux device-tree, as Linux doesn't need it... so he is left in a 
> Catch-22.
>
> A way forward may be to go back to his original approach and get the U-Boot
> driver functionality updated so that it works similarly to the Linux driver
> (and thus can use the same device-tree stanza)?

Let's go back to the original approach and see what happens.

Regards,
Bin


Re: pull request of u-boot-fsl-qoriq for v2022.01

2021-11-11 Thread Tom Rini
On Thu, Nov 11, 2021 at 04:27:09AM +, Priyanka Jain wrote:

> Dear Tom,
> 
> Please find my pull-request for u-boot-fsl-qoriq/master
> https://github.com/u-boot/u-boot/pull/99
> 
> Summary
> fsl-qoriq:
> device-tree sync-up with Linux for ls1028a
> fixes/update in fsl-ddr driver, fsl-validate, lx2162a, fsl-mc, spintable 
> code, configs, qspi node, pci
> enable EFI_SET_TIME support in sl28
> powerpc: Drop -mstring
> 
> 
> Regards
> Priyanka

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Testing pci_mvebu.c with Kirkwood SoCs

2021-11-11 Thread Pali Rohár
On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote:
> I've also tried mdelay(3000), just to be sure. The result was the same
> hang in 'usb start'.

Ok. So put pci_init() into board_late_init().

There are some more cleanup and fixes patches for pci_mvebu.c on mailing
list. After they are merged I will prepare and send final PCI Kirkwood
patch for testing.


Re: [PATCH v2 2/2] board: traverse: add initial Ten64 support

2021-11-11 Thread Tom Rini
On Wed, Nov 10, 2021 at 04:46:39AM +, Mathew McBride wrote:

> The Ten64 is a networking-oriented MiniITX board
> using the NXP LS1088A SoC.
> 
> This patch provides the bare minimum to support
> Ten64 boards under U-Boot for distroboot.
> 
> Some related drivers have not yet been submitted
> and this basic support lacks some of the
> opinionated defaults provided by our firmware
> distribution.
> 
> Signed-off-by: Mathew McBride 
> ---
>  arch/arm/Kconfig   |  16 ++
>  arch/arm/dts/Makefile  |   2 +
>  arch/arm/dts/fsl-ls1088a-ten64.dts | 377 +

What is the status of this dts with upstream Linux?

[snip]
> +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
> earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 default_hugepagesz=2m 
> hugepagesz=2m hugepages=256"

Note that ramdisk information will be passed along correctly via DT and
should not generally be set in this manner.

[snip]
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=spi-nand0:8m(reserved),32m(recovery),108m(ubia),108m(ubib);nor1:1m(bl2),2m(bl3),2m(mcfirmware),512k(ubootenv),256k(dpl),256k(dpc),256k(devicetree)"

This should be the same as the fixed-partition in the dts and then not
needed here.
> diff --git a/include/configs/ten64.h b/include/configs/ten64.h
> new file mode 100644
> index 00..54e65f29f1
> --- /dev/null
> +++ b/include/configs/ten64.h

Please make sure there's no already migrated CONFIG symbols in this.  A
quick 'git log configs' should make it clear what's been migrated to
Kconfig since you last checked this.

> +#define QSPI_NOR_BOOTCOMMAND "run distro_bootcmd"
> +#define SD_BOOTCOMMAND   "run distro_bootcmd"

You should just set CONFIG_USE_BOOTCOMMAND and then CONFIG_BOOTCOMMAND
will be "run distro_bootcmd".  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


[u-boot-test-hooks] writer: Add imx_raw variant

2021-11-11 Thread Tom Rini
When flashing the SD card for an imx platform, we need to use
u-boot-with-spl.imx at an offset of 1024 bytes in to the device.

Signed-off-by: Tom Rini 
---
 bin/writer.imx_raw | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100755 bin/writer.imx_raw

diff --git a/bin/writer.imx_raw b/bin/writer.imx_raw
new file mode 100755
index ..4708bab3ca28
--- /dev/null
+++ b/bin/writer.imx_raw
@@ -0,0 +1,39 @@
+# Copyright 2021 Konsulko Group, All rights reserved.
+# Based on writer.sunxi_raw which is
+# Copyright 2019 Google LLC. All rights reserved.
+#
+# 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 OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+# Writes raw imx images to the board
+
+# Args:
+#  $1: Device path of the sdcard when board is off (e.g. /dev/sdcard0)
+#  $2: U-Boot build directory
+
+set -e
+
+device=$1
+build=$2
+
+echo "Writing to ${device} from build at ${build}"
+
+# At least partially zero out the previous image
+dd if=/dev/zero of=$device bs=1k seek=1 count=128
+dd if=${build}/u-boot-with-spl.imx of=$device bs=1024 seek=1
+sync $device
-- 
2.25.1



Re: [u-boot-test-hooks PATCH 6/7] kea: Add samus

2021-11-11 Thread Tom Rini
On Sat, Oct 30, 2021 at 12:25:38PM -0600, Simon Glass wrote:

> Add a config for samus, the Chromebook Pixel 2.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [u-boot-test-hooks PATCH 5/7] Update sdwire script to wait for umount

2021-11-11 Thread Tom Rini
On Sat, Oct 30, 2021 at 12:25:37PM -0600, Simon Glass wrote:

> Sometimes the umount takes a while. Add the same wait loop as is used for
> mount. Also rename the 'done' variable to 'complete' to void confusing it
> with the end of the for loop.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [u-boot-test-hooks PATCH 4/7] Add wait_raw_device for common code

2021-11-11 Thread Tom Rini
On Sat, Oct 30, 2021 at 12:25:36PM -0600, Simon Glass wrote:

> This code is duplicated in two scripts. Put it into a new wait_raw_device
> to avoid this. Also rename the 'done' variable to 'complete' to void
> confusing it with the end of the for loop.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [u-boot-test-hooks PATCH 3/7] rpi3: Tweak the grep pattern

2021-11-11 Thread Tom Rini
On Sat, Oct 30, 2021 at 12:25:35PM -0600, Simon Glass wrote:

> Just to be safe, check for the pattern only at the start of a line, since
> it is possible to add a comment with this in it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [u-boot-test-hooks PATCH 2/7] sdwire: Tidy up the mount script

2021-11-11 Thread Tom Rini
On Sat, Oct 30, 2021 at 12:25:34PM -0600, Simon Glass wrote:

> Add a comment about the tools and drop the debugging, since this seems
> reliable now.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [u-boot-test-hooks PATCH 1/7] travis-ci: Add qemu_arm_spl board

2021-11-11 Thread Tom Rini
On Sat, Oct 30, 2021 at 12:25:33PM -0600, Simon Glass wrote:

> From: Tuomas Tynkkynen 
> 
> This is similar to the existing qemu_arm target, except that the 'bios' is
> image.bin (containing both SPL and U-Boot) rather than in u-boot.bin
> 
> Signed-off-by: Simon Glass 

Aside from the wrong-From, for a v2 in the future, I'm holding off on
this until the passage stuff which makes use of this, is closer to going
in.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V3 1/5] imx: imx8mq_evk: switch to binman

2021-11-11 Thread Heiko Thiery
Hi Peng,

Am Fr., 22. Okt. 2021 um 04:07 Uhr schrieb Peng Fan (OSS)
:
>
> From: Peng Fan 
>
> Switch to use binman to pack images

After switching to binman you will hit the same issue I have in the
u-boot CI. The mkimage step will fail because the hdmi firmware blob
can not be found [1]. There is already a discuusion ongoing how to fix
that [2].

[1] https://lists.denx.de/pipermail/u-boot/2021-October/464338.html
[2] https://lists.denx.de/pipermail/u-boot/2021-November/466181.html

>
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/dts/imx8mq-evk-u-boot.dtsi |   2 +
>  arch/arm/dts/imx8mq-u-boot.dtsi | 122 
>  arch/arm/mach-imx/imx8m/Kconfig |   1 +
>  board/freescale/imx8mq_evk/Kconfig  |   2 +-
>  board/freescale/imx8mq_evk/imximage.cfg |  11 +++
>  configs/imx8mq_evk_defconfig|   2 +-
>  6 files changed, 138 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/dts/imx8mq-u-boot.dtsi
>  create mode 100644 board/freescale/imx8mq_evk/imximage.cfg
>
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi 
> b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> index 2cfc12b7e0..6f9c81462e 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -1,5 +1,7 @@
>  // SPDX-License-Identifier: (GPL-2.0 OR MIT)
>
> +#include "imx8mq-u-boot.dtsi"
> +
>  &usdhc1 {
> mmc-hs400-1_8v;
>  };
> diff --git a/arch/arm/dts/imx8mq-u-boot.dtsi b/arch/arm/dts/imx8mq-u-boot.dtsi
> new file mode 100644
> index 00..2c10e9b645
> --- /dev/null
> +++ b/arch/arm/dts/imx8mq-u-boot.dtsi
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +/ {
> +   binman: binman {
> +   multiple-images;
> +   };
> +
> +};
> +
> +&binman {
> +   u-boot-spl-ddr {
> +   filename = "u-boot-spl-ddr.bin";
> +   pad-byte = <0xff>;
> +   align-size = <4>;
> +   align = <4>;
> +
> +   u-boot-spl {
> +   align-end = <4>;
> +   };
> +
> +   blob_1: blob-ext@1 {
> +   filename = "lpddr4_pmu_train_1d_imem.bin";
> +   size = <0x8000>;
> +   };
> +
> +   blob_2: blob-ext@2 {
> +   filename = "lpddr4_pmu_train_1d_dmem.bin";
> +   size = <0x4000>;
> +   };
> +
> +   blob_3: blob-ext@3 {
> +   filename = "lpddr4_pmu_train_2d_imem.bin";
> +   size = <0x8000>;
> +   };
> +
> +   blob_4: blob-ext@4 {
> +   filename = "lpddr4_pmu_train_2d_dmem.bin";
> +   size = <0x4000>;
> +   };
> +   };
> +
> +   signed_hdmi {
> +   filename = "signed_hdmi.bin";
> +
> +   blob_5: blob-ext@5 {
> +   filename = "signed_hdmi_imx8m.bin";
> +   };
> +   };
> +
> +   flash {
> +   mkimage {
> +   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
> 0x7e1000";
> +
> +   blob {
> +   filename = "u-boot-spl-ddr.bin";
> +   };
> +
> +   };
> +
> +   };
> +
> +   itb {
> +   filename = "u-boot.itb";
> +
> +   fit {
> +   description = "Configuration to load ATF before 
> U-Boot";
> +   #address-cells = <1>;
> +   fit,external-offset = ;
> +
> +   images {
> +   uboot {
> +   description = "U-Boot (64-bit)";
> +   type = "standalone";
> +   arch = "arm64";
> +   compression = "none";
> +   load = ;
> +
> +   uboot_blob: blob-ext {
> +   filename = "u-boot-nodtb.bin";
> +   };
> +   };
> +
> +   atf {
> +   description = "ARM Trusted Firmware";
> +   type = "firmware";
> +   arch = "arm64";
> +   compression = "none";
> +   load = <0x91>;
> +   entry = <0x91>;
> +
> +   atf_blob: blob-ext {
> +   filename = "bl31.bin";
> +   };
> +   };
> +
> +   fdt {
> +   description = "NAME";
> +   

Re: [PATCH V3 4/5] imx: imx8mq use common imximage.cfg

2021-11-11 Thread Heiko Thiery
Hi Peng,

Am Fr., 22. Okt. 2021 um 04:08 Uhr schrieb Peng Fan (OSS)
:
>
> From: Peng Fan 
>
> After all these board switch to binman, we could use common imximage.cfg
>
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/mach-imx/imx8m/imximage.cfg  | 12 +++-
>  board/freescale/imx8mq_evk/Kconfig|  2 +-
>  board/freescale/imx8mq_evk/imximage.cfg   | 11 ---
>  board/google/imx8mq_phanbell/Kconfig  |  2 +-
>  board/google/imx8mq_phanbell/imximage.cfg | 11 ---
>  board/technexion/pico-imx8mq/Kconfig  |  2 +-
>  board/technexion/pico-imx8mq/imximage.cfg | 11 ---
>  7 files changed, 6 insertions(+), 45 deletions(-)
>  delete mode 100644 board/freescale/imx8mq_evk/imximage.cfg
>  delete mode 100644 board/google/imx8mq_phanbell/imximage.cfg
>  delete mode 100644 board/technexion/pico-imx8mq/imximage.cfg
>
> diff --git a/arch/arm/mach-imx/imx8m/imximage.cfg 
> b/arch/arm/mach-imx/imx8m/imximage.cfg
> index 714b24273b..9c6eaf0a6d 100644
> --- a/arch/arm/mach-imx/imx8m/imximage.cfg
> +++ b/arch/arm/mach-imx/imx8m/imximage.cfg
> @@ -1,17 +1,11 @@
>  /* SPDX-License-Identifier: GPL-2.0+ */
>  /*
> - * Copyright 2018 NXP
> + * Copyright 2018-2021 NXP
>   */
>
>  #define __ASSEMBLY__
>
>  FIT
>  BOOT_FROM  sd
> -SIGNED_HDMIsigned_hdmi_imx8m.bin
> -LOADER spl/u-boot-spl-ddr.bin  0x7E1000
> -SECOND_LOADER  u-boot.itb  0x4020 0x6
> -
> -DDR_FW lpddr4_pmu_train_1d_imem.bin
> -DDR_FW lpddr4_pmu_train_1d_dmem.bin
> -DDR_FW lpddr4_pmu_train_2d_imem.bin
> -DDR_FW lpddr4_pmu_train_2d_dmem.bin
> +SIGNED_HDMIsigned_hdmi.bin
> +LOADER mkimage.flash.mkimage   0x7e1000

This file is only a temporarily created file by binman. You should use
the output file .. here it should be flash.bin.

But as Patrick already pointed out, we should create the final
flash.bin like before. I also have a patch for adding a new im8mq
board pending that has this already implemented.[1].

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20211014180824.10681-2-heiko.thi...@gmail.com/

> diff --git a/board/freescale/imx8mq_evk/Kconfig 
> b/board/freescale/imx8mq_evk/Kconfig
> index a7c49744b3..c4d20ad7c7 100644
> --- a/board/freescale/imx8mq_evk/Kconfig
> +++ b/board/freescale/imx8mq_evk/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
> default "imx8mq_evk"
>
>  config IMX_CONFIG
> -   default "board/freescale/imx8mq_evk/imximage.cfg"
> +   default "arch/arm/mach-imx/imx8m/imximage.cfg"
>
>  endif
> diff --git a/board/freescale/imx8mq_evk/imximage.cfg 
> b/board/freescale/imx8mq_evk/imximage.cfg
> deleted file mode 100644
> index 74f12b30d2..00
> --- a/board/freescale/imx8mq_evk/imximage.cfg
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright 2021 NXP
> - */
> -
> -#define __ASSEMBLY__
> -
> -FIT
> -BOOT_FROM  sd
> -SIGNED_HDMIsigned_hdmi.bin
> -LOADER mkimage.flash.mkimage   0x7e1000
> diff --git a/board/google/imx8mq_phanbell/Kconfig 
> b/board/google/imx8mq_phanbell/Kconfig
> index e59b03cb17..54cfb99952 100644
> --- a/board/google/imx8mq_phanbell/Kconfig
> +++ b/board/google/imx8mq_phanbell/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
> default "imx8mq_phanbell"
>
>  config IMX_CONFIG
> -   default "board/google/imx8mq_phanbell/imximage.cfg"
> +   default "arch/arm/mach-imx/imx8m/imximage.cfg"
>
>  endif
> diff --git a/board/google/imx8mq_phanbell/imximage.cfg 
> b/board/google/imx8mq_phanbell/imximage.cfg
> deleted file mode 100644
> index 74f12b30d2..00
> --- a/board/google/imx8mq_phanbell/imximage.cfg
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright 2021 NXP
> - */
> -
> -#define __ASSEMBLY__
> -
> -FIT
> -BOOT_FROM  sd
> -SIGNED_HDMIsigned_hdmi.bin
> -LOADER mkimage.flash.mkimage   0x7e1000
> diff --git a/board/technexion/pico-imx8mq/Kconfig 
> b/board/technexion/pico-imx8mq/Kconfig
> index 97655517d8..628b051149 100644
> --- a/board/technexion/pico-imx8mq/Kconfig
> +++ b/board/technexion/pico-imx8mq/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
> default "pico-imx8mq"
>
>  config IMX_CONFIG
> -   default "board/technexion/pico-imx8mq/imximage.cfg"
> +   default "arch/arm/mach-imx/imx8m/imximage.cfg"
>
>  endif
> diff --git a/board/technexion/pico-imx8mq/imximage.cfg 
> b/board/technexion/pico-imx8mq/imximage.cfg
> deleted file mode 100644
> index 74f12b30d2..00
> --- a/board/technexion/pico-imx8mq/imximage.cfg
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright 2021 NXP
> - */
> -
> -#define __ASSEMBLY__
> -
> -FIT
> -BOOT_FROM  sd
> -SIGNED_HDMIsigned_hdmi.bin
> -LOADER mkimage.flash.mkimage   0x7e1000
> --
> 2.30.0
>


Re: [PATCH v2 5/5] vexpress64: Enable VIRTIO_NET network driver

2021-11-11 Thread Andre Przywara
On Thu, 11 Nov 2021 09:26:03 +
Peter Hoyes  wrote:

> From: Peter Hoyes 
> 
> The SMSC driver is using the old driver model.
> 
> Init the virtio system in vexpress64.c so that the network device is
> discovered.
> 
> Signed-off-by: Peter Hoyes 

Looks like the same as v1, so repeating my tag:

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/armltd/vexpress64/vexpress64.c | 7 +++
>  include/configs/vexpress_aemv8.h | 4 ++--
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/board/armltd/vexpress64/vexpress64.c 
> b/board/armltd/vexpress64/vexpress64.c
> index d17b463be5..5e22e89824 100644
> --- a/board/armltd/vexpress64/vexpress64.c
> +++ b/board/armltd/vexpress64/vexpress64.c
> @@ -18,6 +18,10 @@
>  #include 
>  #include "pcie.h"
>  #include 
> +#ifdef CONFIG_VIRTIO_NET
> +#include 
> +#include 
> +#endif
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -64,6 +68,9 @@ __weak void vexpress64_pcie_init(void)
>  int board_init(void)
>  {
>   vexpress64_pcie_init();
> +#ifdef CONFIG_VIRTIO_NET
> + virtio_init();
> +#endif
>   return 0;
>  }
>  
> diff --git a/include/configs/vexpress_aemv8.h 
> b/include/configs/vexpress_aemv8.h
> index 7cdfc30649..faa7065086 100644
> --- a/include/configs/vexpress_aemv8.h
> +++ b/include/configs/vexpress_aemv8.h
> @@ -88,8 +88,8 @@
>  #endif
>  #endif /* !CONFIG_GICV3 */
>  
> -#ifndef CONFIG_TARGET_VEXPRESS64_JUNO
> -/* The Vexpress64 simulators use SMSC91C111 */
> +#if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) && !defined(CONFIG_DM_ETH)
> +/* The Vexpress64 BASE_FVP simulator uses SMSC91C111 */
>  #define CONFIG_SMC9  1
>  #define CONFIG_SMC9_BASE (V2M_PA_BASE + 0x01A00)
>  #endif



Re: [PATCH v2 4/5] vexpress64: Enable OF_CONTROL and OF_BOARD for VExpress64

2021-11-11 Thread Andre Przywara
On Thu, 11 Nov 2021 09:26:02 +
Peter Hoyes  wrote:

> From: Peter Hoyes 
> 
> Capture x0 in lowlevel_init.S as potential fdt address. Modify
> board_fdt_blob_setup to use fdt address from either vexpress_aemv8.h
> or lowlevel_init.S.
> 

Thanks, looks good now:

> Signed-off-by: Peter Hoyes 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/armltd/vexpress64/Makefile|  2 +-
>  board/armltd/vexpress64/lowlevel_init.S | 12 
>  board/armltd/vexpress64/vexpress64.c| 26 +
>  3 files changed, 39 insertions(+), 1 deletion(-)
>  create mode 100644 board/armltd/vexpress64/lowlevel_init.S
> 
> diff --git a/board/armltd/vexpress64/Makefile 
> b/board/armltd/vexpress64/Makefile
> index 868dc4f629..1878fbed4e 100644
> --- a/board/armltd/vexpress64/Makefile
> +++ b/board/armltd/vexpress64/Makefile
> @@ -3,5 +3,5 @@
>  # (C) Copyright 2000-2004
>  # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>  
> -obj-y:= vexpress64.o
> +obj-y:= vexpress64.o lowlevel_init.o
>  obj-$(CONFIG_TARGET_VEXPRESS64_JUNO) += pcie.o
> diff --git a/board/armltd/vexpress64/lowlevel_init.S 
> b/board/armltd/vexpress64/lowlevel_init.S
> new file mode 100644
> index 00..3dcfb85d0e
> --- /dev/null
> +++ b/board/armltd/vexpress64/lowlevel_init.S
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * (C) Copyright 2021 Arm Limited
> + */
> +
> +.global save_boot_params
> +save_boot_params:
> +
> + adr x8, prior_stage_fdt_address
> + str x0, [x8]
> +
> + b   save_boot_params_ret
> diff --git a/board/armltd/vexpress64/vexpress64.c 
> b/board/armltd/vexpress64/vexpress64.c
> index d2f307cca5..d17b463be5 100644
> --- a/board/armltd/vexpress64/vexpress64.c
> +++ b/board/armltd/vexpress64/vexpress64.c
> @@ -85,7 +85,15 @@ int dram_init_banksize(void)
>   return 0;
>  }
>  
> +/* Assigned in lowlevel_init.S
> + * Push the variable into the .data section so that it
> + * does not get cleared later.
> + */
> +unsigned long __section(".data") prior_stage_fdt_address;
> +
>  #ifdef CONFIG_OF_BOARD
> +
> +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
>  #define JUNO_FLASH_SEC_SIZE  (256 * 1024)
>  static phys_addr_t find_dtb_in_nor_flash(const char *partname)
>  {
> @@ -130,9 +138,11 @@ static phys_addr_t find_dtb_in_nor_flash(const char 
> *partname)
>  
>   return ~0;
>  }
> +#endif
>  
>  void *board_fdt_blob_setup(int *err)
>  {
> +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
>   phys_addr_t fdt_rom_addr = find_dtb_in_nor_flash(CONFIG_JUNO_DTB_PART);
>  
>   *err = 0;
> @@ -142,6 +152,22 @@ void *board_fdt_blob_setup(int *err)
>   }
>  
>   return (void *)fdt_rom_addr;
> +#endif
> +
> +#ifdef VEXPRESS_FDT_ADDR
> + if (fdt_magic(VEXPRESS_FDT_ADDR) == FDT_MAGIC) {
> + *err = 0;
> + return (void *)VEXPRESS_FDT_ADDR;
> + }
> +#endif
> +
> + if (fdt_magic(prior_stage_fdt_address) == FDT_MAGIC) {
> + *err = 0;
> + return (void *)prior_stage_fdt_address;
> + }
> +
> + *err = -ENXIO;
> + return NULL;
>  }
>  #endif
>  



Re: [PATCH v2 3/5] vexpress64: Clean up BASE_FVP boot configuration

2021-11-11 Thread Andre Przywara
On Thu, 11 Nov 2021 09:26:01 +
Peter Hoyes  wrote:

> From: Peter Hoyes 
> 
> Move env var address values to #defines so they can be reused elsewhere.
> 
> Rename env var names to those recommended in the README and modify
> addresses to allow more space for the kernel.
> 
> Fix issue where fdt is called with invalid arguments when booting
> without a ramdisk.
> 
> Signed-off-by: Peter Hoyes 

Ah, more air to breathe now, thanks!

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  include/configs/vexpress_aemv8.h | 50 
>  1 file changed, 31 insertions(+), 19 deletions(-)
> 
> diff --git a/include/configs/vexpress_aemv8.h 
> b/include/configs/vexpress_aemv8.h
> index 49517a60b0..7cdfc30649 100644
> --- a/include/configs/vexpress_aemv8.h
> +++ b/include/configs/vexpress_aemv8.h
> @@ -7,6 +7,8 @@
>  #ifndef __VEXPRESS_AEMV8_H
>  #define __VEXPRESS_AEMV8_H
>  
> +#include 
> +
>  #define CONFIG_REMAKE_ELF
>  
>  /* Link Definitions */
> @@ -172,33 +174,43 @@
>   BOOTENV
>  
>  #elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
> +
> +#define VEXPRESS_KERNEL_ADDR 0x8008
> +#define VEXPRESS_FDT_ADDR0x8fc0
> +#define VEXPRESS_BOOT_ADDR   0x8fd0
> +#define VEXPRESS_RAMDISK_ADDR0x8fe0
> +
>  #define CONFIG_EXTRA_ENV_SETTINGS\
>   "kernel_name=Image\0"   \
> - "kernel_addr=0x8008\0"  \
> - "initrd_name=ramdisk.img\0" \
> - "initrd_addr=0x8800\0"  \
> - "fdtfile=devtree.dtb\0" \
> - "fdt_addr=0x8300\0" \
> - "boot_name=boot.img\0"  \
> - "boot_addr=0x8007f800\0"
> + "kernel_addr_r=" 
> __stringify(VEXPRESS_KERNEL_ADDR) "\0" \
> + "ramdisk_name=ramdisk.img\0"\
> + "ramdisk_addr_r=" 
> __stringify(VEXPRESS_RAMDISK_ADDR) "\0" \
> + "fdtfile=devtree.dtb\0" \
> + "fdt_addr_r=" __stringify(VEXPRESS_FDT_ADDR) 
> "\0"   \
> + "boot_name=boot.img\0" \
> + "boot_addr_r=" __stringify(VEXPRESS_BOOT_ADDR) 
> "\0"
>  
>  #ifndef CONFIG_BOOTCOMMAND
> -#define CONFIG_BOOTCOMMAND   "if smhload ${boot_name} ${boot_addr}; then " \
> +#define CONFIG_BOOTCOMMAND   "if smhload ${boot_name} ${boot_addr_r}; then " 
> \
>   "  set bootargs; " \
> - "  abootimg addr ${boot_addr}; " \
> - "  abootimg get dtb --index=0 fdt_addr; " \
> - "  bootm ${boot_addr} ${boot_addr} " \
> - "  ${fdt_addr}; " \
> + "  abootimg addr ${boot_addr_r}; " \
> + "  abootimg get dtb --index=0 fdt_addr_r; " \
> + "  bootm ${boot_addr_r} ${boot_addr_r} " \
> + "  ${fdt_addr_r}; " \
>   "else; " \
>   "  set fdt_high 0x; " \
>   "  set initrd_high 0x; " \
> - "  smhload ${kernel_name} ${kernel_addr}; " \
> - "  smhload ${fdtfile} ${fdt_addr}; " \
> - "  smhload ${initrd_name} ${initrd_addr} "\
> - "  initrd_end; " \
> - "  fdt addr ${fdt_addr}; fdt resize; " \
> - "  fdt chosen ${initrd_addr} ${initrd_end}; " \
> - "  booti $kernel_addr - $fdt_addr; " \
> + "  smhload ${kernel_name} ${kernel_addr_r}; " \
> + "  smhload ${fdtfile} ${fdt_addr_r}; " \
> + "  smhload ${ramdisk_name} ${ramdisk_addr_r} "\
> + "  ramdisk_end; " \
> + "  fdt addr ${fdt_addr_r}; fdt resize; " \
> + "  if test -n ${ramdisk_end}; then "\
> + "fdt chosen ${ramdisk_addr_r} 
> ${ramdisk_end}; " \
> + "  else; " \
> + "fdt chosen; " \
> + "  fi; " \
> + "  booti $kernel_addr_r - $fdt_addr_r; " \
>   "fi"
>  #endif
>  



Re: [PATCH v2 2/5] vexpress64: Refactor header file to make it easier to add new FVPs

2021-11-11 Thread Andre Przywara
On Thu, 11 Nov 2021 09:26:00 +
Peter Hoyes  wrote:

Hi Peter,

> From: Peter Hoyes 
> 
> Rename from vexpress_aemv8a.h -> vepxress_aemv8.h as new FVPs may not be
> v8-A. No change in behavior.
> 
> This is towards future work to enable support for the FVP_BaseR.
> 
> Signed-off-by: Peter Hoyes 

Please carry over Reviewed-by: tags from former revisions, when you don't
change a patch. That not only helps the maintainer to see at one glance
what is missing, but also the reviewers, who know what patch to skip ;-)

As diff told me that v1 and v2 are identical, for the records:

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/armltd/vexpress64/Kconfig   |  2 +-
>  doc/README.semihosting|  2 +-
>  .../{vexpress_aemv8a.h => vexpress_aemv8.h}   | 48 ++-
>  3 files changed, 27 insertions(+), 25 deletions(-)
>  rename include/configs/{vexpress_aemv8a.h => vexpress_aemv8.h} (88%)
> 
> diff --git a/board/armltd/vexpress64/Kconfig
> b/board/armltd/vexpress64/Kconfig index 1d13f542e6..4aab3f092e 100644
> --- a/board/armltd/vexpress64/Kconfig
> +++ b/board/armltd/vexpress64/Kconfig
> @@ -7,7 +7,7 @@ config SYS_VENDOR
>   default "armltd"
>  
>  config SYS_CONFIG_NAME
> - default "vexpress_aemv8a"
> + default "vexpress_aemv8"
>  
>  config JUNO_DTB_PART
>   string "NOR flash partition holding DTB"
> diff --git a/doc/README.semihosting b/doc/README.semihosting
> index c01bed..f382d0131e 100644
> --- a/doc/README.semihosting
> +++ b/doc/README.semihosting
> @@ -25,7 +25,7 @@ or turning on CONFIG_BASE_FVP for the more full
> featured model. Rather than create a new armv8 board similar to
> armltd/vexpress64, add semihosting calls to the existing one, enabled
> with CONFIG_SEMIHOSTING and CONFIG_BASE_FVP both set. Also reuse the
> existing board config file -vexpress_aemv8a.h but differentiate the two
> models by the presence or +vexpress_aemv8.h but differentiate the two
> models by the presence or absence of CONFIG_BASE_FVP. This change is
> tested and works on both the Foundation and Base fastmodel simulators.
>  
> diff --git a/include/configs/vexpress_aemv8a.h
> b/include/configs/vexpress_aemv8.h similarity index 88%
> rename from include/configs/vexpress_aemv8a.h
> rename to include/configs/vexpress_aemv8.h
> index df22584d9a..49517a60b0 100644
> --- a/include/configs/vexpress_aemv8a.h
> +++ b/include/configs/vexpress_aemv8.h
> @@ -4,36 +4,37 @@
>   *   configurations.
>   */
>  
> -#ifndef __VEXPRESS_AEMV8A_H
> -#define __VEXPRESS_AEMV8A_H
> +#ifndef __VEXPRESS_AEMV8_H
> +#define __VEXPRESS_AEMV8_H
>  
>  #define CONFIG_REMAKE_ELF
>  
>  /* Link Definitions */
> -#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
> +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
> +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +
> 0x7fff0) +#else
>  /* ATF loads u-boot here for BASE_FVP model */
>  #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +
> 0x03f0) -#elif CONFIG_TARGET_VEXPRESS64_JUNO
> -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +
> 0x7fff0) #endif
>  
>  #define CONFIG_SYS_BOOTM_LEN (64 << 20)  /* Increase max gunzip
> size */ 
>  /* CS register bases for the original memory map. */
> -#define V2M_PA_CS0   0x
> -#define V2M_PA_CS1   0x1400
> -#define V2M_PA_CS2   0x1800
> -#define V2M_PA_CS3   0x1c00
> -#define V2M_PA_CS4   0x0c00
> -#define V2M_PA_CS5   0x1000
> +#define V2M_BASE 0x8000
> +#define V2M_PA_BASE  0x
> +
> +#define V2M_PA_CS0   (V2M_PA_BASE + 0x)
> +#define V2M_PA_CS1   (V2M_PA_BASE + 0x1400)
> +#define V2M_PA_CS2   (V2M_PA_BASE + 0x1800)
> +#define V2M_PA_CS3   (V2M_PA_BASE + 0x1c00)
> +#define V2M_PA_CS4   (V2M_PA_BASE + 0x0c00)
> +#define V2M_PA_CS5   (V2M_PA_BASE + 0x1000)
>  
>  #define V2M_PERIPH_OFFSET(x) (x << 16)
>  #define V2M_SYSREGS  (V2M_PA_CS3 +
> V2M_PERIPH_OFFSET(1)) #define V2M_SYSCTL
> (V2M_PA_CS3 + V2M_PERIPH_OFFSET(2)) #define V2M_SERIAL_BUS_PCI
>   (V2M_PA_CS3 + V2M_PERIPH_OFFSET(3)) 
> -#define V2M_BASE 0x8000
> -
>  /* Common peripherals relative to CS7. */
>  #define V2M_AACI (V2M_PA_CS3 +
> V2M_PERIPH_OFFSET(4)) #define V2M_MMCI
> (V2M_PA_CS3 + V2M_PERIPH_OFFSET(5)) @@ -72,23 +73,23 @@
>  
>  /* Generic Interrupt Controller Definitions */
>  #ifdef CONFIG_GICV3
> -#define GICD_BASE(0x2f00)
> -#define GICR_BASE(0x2f10)
> +#define GICD_BASE(V2M_PA_BASE + 0x2f00)
> +#define GICR_BASE(V2M_PA_BASE + 0x2f10)
>  #else
>  
> -#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
> -#define GICD_BASE(0x2f000

Re: [PATCH v2 1/5] doc: Add documentation for the Arm VExpress64 board configs

2021-11-11 Thread Andre Przywara
On Thu, 11 Nov 2021 09:25:59 +
Peter Hoyes  wrote:

> From: Peter Hoyes 
> 
> Create a new documentation section for Arm Ltd boards with a sub-page
> for the VExpress64 boards (FVP-A and Juno).

Thanks for the changes, looks good now:

> Signed-off-by: Peter Hoyes 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  doc/board/armltd/index.rst  |  9 ++
>  doc/board/armltd/vexpress64.rst | 51 +
>  doc/board/index.rst |  1 +
>  3 files changed, 61 insertions(+)
>  create mode 100644 doc/board/armltd/index.rst
>  create mode 100644 doc/board/armltd/vexpress64.rst
> 
> diff --git a/doc/board/armltd/index.rst b/doc/board/armltd/index.rst
> new file mode 100644
> index 00..c20d8a0a26
> --- /dev/null
> +++ b/doc/board/armltd/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Arm Ltd
> +=
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   vexpress64.rst
> diff --git a/doc/board/armltd/vexpress64.rst b/doc/board/armltd/vexpress64.rst
> new file mode 100644
> index 00..d87b1c38f5
> --- /dev/null
> +++ b/doc/board/armltd/vexpress64.rst
> @@ -0,0 +1,51 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Arm Versatile Express
> +=
> +
> +The vexpress_* board configuration supports the following platforms:
> +
> + * FVP_Base_RevC-2xAEMvA
> + * Juno development board
> +
> +Fixed Virtual Platforms
> +---
> +
> +The Fixed Virtual Platforms (FVP) are complete simulations of an Arm system,
> +including processor, memory and peripherals. They are set out in a 
> "programmer's
> +view", which gives a comprehensive model on which to build and test software.
> +
> +The supported FVPs are available free of charge and can be downloaded from 
> the
> +Arm developer site [1]_ (user registration might be required).
> +
> +Supported features:
> +
> + * GICv3
> + * Generic timer
> + * PL011 UART
> +
> +The default configuration assumes that U-Boot is bootstrapped using a 
> suitable
> +bootloader, such as Trusted Firmware-A [4]_. The u-boot binary can be passed
> +into the TF-A build: ``make PLAT= all fip BL33=u-boot.bin``
> +
> +The FVPs can be debugged using Arm Development Studio [2]_.
> +
> +Juno
> +
> +
> +Juno is an Arm development board with the following features:
> +
> + * Arm Cortex-A72/A57 and Arm Cortex-A53 in a "big.LITTLE" configuration
> + * A PCIe Gen2.0 bus with 4 lanes
> + * 8GB of DRAM
> + * GICv2
> +
> +More details can be found in the board documentation [3]_.
> +
> +References
> +--
> +
> +.. [1] 
> https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
> +.. [2] 
> https://developer.arm.com/tools-and-software/embedded/arm-development-studio
> +.. [3] 
> https://developer.arm.com/tools-and-software/development-boards/juno-development-board
> +.. [4] https://trustedfirmware-a.readthedocs.io/
> \ No newline at end of file
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 74ea33e081..78b486538b 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -11,6 +11,7 @@ Board-specific doc
> AndesTech/index
> amlogic/index
> apple/index
> +   armltd/index
> atmel/index
> congatec/index
> coreboot/index



[PATCH u-boot-marvell 4/5] SPL: Add support for checking board / BootROM specific image types

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Commit 9baab60b8054 ("SPL: Add support for parsing board / BootROM specific
image types") added support for loading board specific image types.

This commit adds support for a new weak function spl_parse_board_header()
which is called after loading boot image. Board may implement this function
for checking if loaded board specific image is valid.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 common/spl/spl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index bf2139a058..cc3b3b3438 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -589,6 +589,12 @@ static struct spl_image_loader *spl_ll_find_loader(uint 
boot_device)
return NULL;
 }
 
+__weak int spl_check_board_image(struct spl_image_info *spl_image,
+const struct spl_boot_device *bootdev)
+{
+   return 0;
+}
+
 static int spl_load_image(struct spl_image_info *spl_image,
  struct spl_image_loader *loader)
 {
@@ -610,6 +616,9 @@ static int spl_load_image(struct spl_image_info *spl_image,
}
}
 #endif
+   if (!ret)
+   ret = spl_check_board_image(spl_image, &bootdev);
+
return ret;
 }
 
-- 
2.32.0



[PATCH u-boot-marvell 5/5] arm: mvebu: Check for kwbimage data checksum

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Last 4 bytes of kwbimage boot image is checksum. Verify it via the new
spl_check_board_image() function which is called by U-Boot SPL after
loading kwbimage.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 arch/arm/mach-mvebu/spl.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 662f430503..f0b84167b9 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -100,6 +100,34 @@ u32 spl_mmc_boot_mode(const u32 boot_device)
 }
 #endif
 
+static uint32_t checksum32(void *start, uint32_t len)
+{
+   uint32_t csum = 0;
+   uint32_t *p = start;
+
+   while (len > 0) {
+   csum += *p++;
+   len -= sizeof(uint32_t);
+   };
+
+   return csum;
+}
+
+int spl_check_board_image(struct spl_image_info *spl_image,
+ const struct spl_boot_device *bootdev)
+{
+   uint32_t csum = *(uint32_t *)(spl_image->load_addr +
+ spl_image->size - 4);
+
+   if (checksum32((void *)spl_image->load_addr,
+  spl_image->size - 4) != csum) {
+   printf("ERROR: Invalid data checksum in kwbimage\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int spl_parse_board_header(struct spl_image_info *spl_image,
   const struct spl_boot_device *bootdev,
   const void *image_header, size_t size)
-- 
2.32.0



[PATCH u-boot-marvell 3/5] arm: mvebu: Check that kwbimage blockid matches boot mode

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Each boot mode has its own kwbimage specified by blockid. So check that
kwbimage is valid by blockid.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 arch/arm/mach-mvebu/spl.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index deef6e76f3..662f430503 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -118,22 +118,36 @@ int spl_parse_board_header(struct spl_image_info 
*spl_image,
 * (including SPL content) which is not included in U-Boot image_header.
 */
if (mhdr->version != 1 ||
-   ((mhdr->headersz_msb << 16) | mhdr->headersz_lsb) < sizeof(*mhdr) ||
-   (
+   ((mhdr->headersz_msb << 16) | mhdr->headersz_lsb) < sizeof(*mhdr)) {
+   printf("ERROR: Invalid kwbimage v1\n");
+   return -EINVAL;
+   }
+
 #ifdef CONFIG_SPL_SPI_FLASH_SUPPORT
-mhdr->blockid != IBR_HDR_SPI_ID &&
+   if (bootdev->boot_device == BOOT_DEVICE_SPI &&
+   mhdr->blockid != IBR_HDR_SPI_ID) {
+   printf("ERROR: Wrong blockid in SPI kwbimage\n");
+   return -EINVAL;
+   }
 #endif
+
 #ifdef CONFIG_SPL_SATA
-mhdr->blockid != IBR_HDR_SATA_ID &&
+   if (bootdev->boot_device == BOOT_DEVICE_SATA &&
+   mhdr->blockid != IBR_HDR_SATA_ID) {
+   printf("ERROR: Wrong blockid in SATA kwbimage\n");
+   return -EINVAL;
+   }
 #endif
+
 #ifdef CONFIG_SPL_MMC
-mhdr->blockid != IBR_HDR_SDIO_ID &&
-#endif
-1
-   )) {
-   printf("ERROR: Not valid SPI/NAND/SATA/SDIO kwbimage v1\n");
+   if ((bootdev->boot_device == BOOT_DEVICE_MMC1 ||
+bootdev->boot_device == BOOT_DEVICE_MMC2 ||
+bootdev->boot_device == BOOT_DEVICE_MMC2_2) &&
+   mhdr->blockid != IBR_HDR_SDIO_ID) {
+   printf("ERROR: Wrong blockid in SDIO kwbimage\n");
return -EINVAL;
}
+#endif
 
spl_image->offset = mhdr->srcaddr;
 
-- 
2.32.0



[PATCH u-boot-marvell 2/5] SPL: Add struct spl_boot_device parameter into spl_parse_board_header()

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Add parameter spl_boot_device to spl_parse_board_header(), which allows
the implementations to see from which device we are booting and do
boot-device-specific checks of the image header.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 arch/arm/mach-mvebu/spl.c   |  1 +
 arch/arm/mach-sunxi/spl_spi_sunxi.c |  2 +-
 common/spl/spl.c|  4 ++-
 common/spl/spl_ext.c|  9 --
 common/spl/spl_fat.c| 11 +---
 common/spl/spl_legacy.c |  3 +-
 common/spl/spl_mmc.c| 43 ++---
 common/spl/spl_nand.c   |  5 ++--
 common/spl/spl_net.c|  2 +-
 common/spl/spl_nor.c|  4 +--
 common/spl/spl_onenand.c|  2 +-
 common/spl/spl_ram.c|  2 +-
 common/spl/spl_sata.c   |  9 +++---
 common/spl/spl_sdp.c|  2 +-
 common/spl/spl_spi.c|  9 +++---
 common/spl/spl_ubi.c|  4 +--
 common/spl/spl_usb.c|  4 +--
 common/spl/spl_xip.c|  4 +--
 common/spl/spl_ymodem.c |  4 +--
 drivers/usb/gadget/f_sdp.c  | 12 
 include/sdp.h   |  3 +-
 include/spl.h   |  7 +
 22 files changed, 90 insertions(+), 56 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 71994e44f1..deef6e76f3 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -101,6 +101,7 @@ u32 spl_mmc_boot_mode(const u32 boot_device)
 #endif
 
 int spl_parse_board_header(struct spl_image_info *spl_image,
+  const struct spl_boot_device *bootdev,
   const void *image_header, size_t size)
 {
const struct kwbimage_main_hdr_v1 *mhdr = image_header;
diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c 
b/arch/arm/mach-sunxi/spl_spi_sunxi.c
index 3499c4cc5f..910e805016 100644
--- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
+++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
@@ -348,7 +348,7 @@ static int spl_spi_load_image(struct spl_image_info 
*spl_image,
ret = spl_load_simple_fit(spl_image, &load,
  load_offset, header);
} else {
-   ret = spl_parse_image_header(spl_image, header);
+   ret = spl_parse_image_header(spl_image, bootdev, header);
if (ret)
return ret;
 
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 4c101ec5d3..bf2139a058 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -312,6 +312,7 @@ static int spl_load_fit_image(struct spl_image_info 
*spl_image,
 #endif
 
 __weak int spl_parse_board_header(struct spl_image_info *spl_image,
+ const struct spl_boot_device *bootdev,
  const void *image_header, size_t size)
 {
return -EINVAL;
@@ -326,6 +327,7 @@ __weak int spl_parse_legacy_header(struct spl_image_info 
*spl_image,
 }
 
 int spl_parse_image_header(struct spl_image_info *spl_image,
+  const struct spl_boot_device *bootdev,
   const struct image_header *header)
 {
 #if CONFIG_IS_ENABLED(LOAD_FIT_FULL)
@@ -369,7 +371,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
}
 #endif
 
-   if (!spl_parse_board_header(spl_image, (const void *)header, 
sizeof(*header)))
+   if (!spl_parse_board_header(spl_image, bootdev, (const void 
*)header, sizeof(*header)))
return 0;
 
 #ifdef CONFIG_SPL_RAW_IMAGE_SUPPORT
diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
index 6a28fe9bdb..ebd914c492 100644
--- a/common/spl/spl_ext.c
+++ b/common/spl/spl_ext.c
@@ -10,6 +10,7 @@
 #include 
 
 int spl_load_image_ext(struct spl_image_info *spl_image,
+  struct spl_boot_device *bootdev,
   struct blk_desc *block_dev, int partition,
   const char *filename)
 {
@@ -46,7 +47,7 @@ int spl_load_image_ext(struct spl_image_info *spl_image,
goto end;
}
 
-   err = spl_parse_image_header(spl_image, header);
+   err = spl_parse_image_header(spl_image, bootdev, header);
if (err < 0) {
puts("spl: ext: failed to parse image header\n");
goto end;
@@ -66,6 +67,7 @@ end:
 
 #if CONFIG_IS_ENABLED(OS_BOOT)
 int spl_load_image_ext_os(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev,
  struct blk_desc *block_dev, int partition)
 {
int err;
@@ -103,7 +105,7 @@ int spl_load_image_ext_os(struct spl_image_info *spl_image,
}
file = env_get("falcon_image_file");
if (file) {
-   err = spl_load_image_ext(spl_image, block_dev,
+   err = spl_load

[PATCH u-boot-marvell 1/5] arm: mvebu: Check that kwbimage offset and blocksize are valid

2021-11-11 Thread Marek Behún
From: Pali Rohár 

There are certain restrictions for kwbimage offset and blocksize.
Validate them.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 arch/arm/mach-mvebu/spl.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 73c4b9af3e..71994e44f1 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -163,6 +163,16 @@ int spl_parse_board_header(struct spl_image_info 
*spl_image,
spl_image->offset *= 512;
 #endif
 
+   if (spl_image->offset % 4 != 0) {
+   printf("ERROR: Wrong srcaddr in kwbimage\n");
+   return -EINVAL;
+   }
+
+   if (mhdr->blocksize <= 4 || mhdr->blocksize % 4 != 0) {
+   printf("ERROR: Wrong blocksize in kwbimage\n");
+   return -EINVAL;
+   }
+
spl_image->size = mhdr->blocksize;
spl_image->entry_point = mhdr->execaddr;
spl_image->load_addr = mhdr->destaddr;
-- 
2.32.0



[PATCH u-boot-marvell 0/5] More verifications for kwbimage in SPL

2021-11-11 Thread Marek Behún
From: Marek Behún 

Hello Stefan,

this series adds more checks for kwbimage validity and consistency to
SPL, mainly checking image data checksum.

Marek

Pali Rohár (5):
  arm: mvebu: Check that kwbimage offset and blocksize are valid
  SPL: Add struct spl_boot_device parameter into
spl_parse_board_header()
  arm: mvebu: Check that kwbimage blockid matches boot mode
  SPL: Add support for checking board / BootROM specific image types
  arm: mvebu: Check for kwbimage data checksum

 arch/arm/mach-mvebu/spl.c   | 71 +
 arch/arm/mach-sunxi/spl_spi_sunxi.c |  2 +-
 common/spl/spl.c| 13 +-
 common/spl/spl_ext.c|  9 ++--
 common/spl/spl_fat.c| 11 +++--
 common/spl/spl_legacy.c |  3 +-
 common/spl/spl_mmc.c| 43 ++---
 common/spl/spl_nand.c   |  5 +-
 common/spl/spl_net.c|  2 +-
 common/spl/spl_nor.c|  4 +-
 common/spl/spl_onenand.c|  2 +-
 common/spl/spl_ram.c|  2 +-
 common/spl/spl_sata.c   |  9 ++--
 common/spl/spl_sdp.c|  2 +-
 common/spl/spl_spi.c|  9 ++--
 common/spl/spl_ubi.c|  4 +-
 common/spl/spl_usb.c|  4 +-
 common/spl/spl_xip.c|  4 +-
 common/spl/spl_ymodem.c |  4 +-
 drivers/usb/gadget/f_sdp.c  | 12 +++--
 include/sdp.h   |  3 +-
 include/spl.h   |  7 +++
 22 files changed, 160 insertions(+), 65 deletions(-)

-- 
2.32.0



Re: [PATCH v2 2/2] board: mntre: imx8mq: Add MNT Reform 2 board support

2021-11-11 Thread Patrick Wildt
On Thu, Nov 11, 2021 at 12:21:26PM +0100, Patrick Wildt wrote:
> On Wed, Nov 10, 2021 at 02:26:54PM -0800, Vagrant Cascadian wrote:
> > On 2021-09-02, Patrick Wildt wrote:
> > > The MNT Reform 2 is a modular DIY laptop.  In its initial version it
> > > is based on the BoundaryDevices i.MX8MQ SoM.  Some parts have been
> > > lifted from BoundaryDevices official U-Boot downstream project.
> > 
> > Thanks for working on this!
> > 
> > I'm struggling a bit getting it to actually boot; how is this supposed
> > to be installed to the device?
> > 
> > I've built with the two applied patches on a patched v2021.10, copying
> > various firmware parts from:
> > 
> >   
> > https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/bl31-iMX8MQ.bin
> >   
> > https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_1d_dmem.bin
> >   
> > https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_1d_imem.bin
> >   
> > https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_2d_dmem.bin
> >   
> > https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_2d_imem.bin
> > 
> >   export BL31=bl31-iMX8MQ.bin
> > 
> >   make imx8mq_reform2_defconfig
> >   make
> >   make flash.bin
> > 
> > Then grepping various other README's from imx8mq devices, I tried two
> > different processes:
> > 
> >   dd if=flash.bin of=/dev/sd[x] bs=1K seek=33
> 
> You only need to dd flash.bin, the command looks fine.

Correction: With Peng's current Binman patchset you need both.  But I
think that is not correct, because for i.MX8MM Binman was changed back
to generate a single image.  The following patch includes that change,
so you only need to dd flash.bin.

> > and:
> > 
> >   dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
> >   dd if=u-boot.itb of=/dev/sd[x] bs=1024 seek=384 conv=sync
> > 
> > Both simply hanging with:
> > 
> >   U-Boot SPL 2021.10 (Jan 01 1970 - 00:00:01 +)
> 
> There have been a few changes in U-Boot since I sent my patchset, it's
> possible the diff by itself might not be enough.
> 
> I will send out a new patchset soon, but the move to Binman doesn't work
> for me yet.  It's weird, because I don't see a diff to other i.MX8MQ
> platforms, so I'm still debugging that.  Maybe the other i.MX8MQ boards
> don't work with Binman either?
> 
> Keep note that the build procedure (how to supply bl31) changes once
> Binman is used.

I have fixed the issue.  My changes depend on Peng's patchset to change
i.MX8MQ to Binman, so I will re-issue a v3 of the patchset as soon as
that is done (to not interfere any further with his patchset).

'Attached' you'll find a complete diff you can apply to origin/master,
which includes some of Peng's changes.  Let me know how it goes for you.

Patrick

> > Is the flash.bin step unecessary? I see DDR timing code in the patch
> > series; are corresponding lpddr4*.bin no longer necessary?
> 
> The flash.bin has all bits: U-Boot, U-Boot SPL, lpddr4*.bin and bl31.bin
> 
> lpddr4*.bin is the firmware for the DDR controller.  So you need the
> timing information *and* the firmware.
> 
> > I also tried building with an old version of arm-trusted-firmware
> > (v2.2), as that was the most recent upstream version that successfully
> > built. This seems to be a fork of ATF that has support for iMX8MQ, but
> > it is unclear which branch/tag/etc. should be used with the mnt/reform:
> > 
> >   https://source.codeaurora.org/external/imx/imx-atf
> 
> Not sure right now, but I think I was using the one that's build on
> OpenBSD-current, which seems to be arm-trusted-firmware 2.5.  I'll
> check it.
> 
> > It would be nice to include a board README in the next patch revision to
> > spell out some of the details of exactly which other projects and
> > versions/comments/branches are expected to work with MNT Reform2.
> > 
> 
> This is nothing specific to the MNT Reform2.  It's the same for all
> i.MX8MQ boards.  ATF+DDR+U-Boot have to work together, and it doesn't
> matter which board it is.  Hence I don't believe providing that kind
> information in a Reform-specific README makes sense.
> 
> Patrick
> 
> > 
> > I would be nice if you could CC me on future patch series revisions to
> > be able to test. Thanks!
> > 
> > 
> > live well,
> >   vagrant

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd8..6c14e9328e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -904,6 +904,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-evk.dtb \
imx8mm-beacon-kit.dtb \
imx8mn-beacon-kit.dtb \
+   imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
imx8mp-evk.dtb \
imx8mp-phyboard-pollux-rdk.dtb \
diff --git a/arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi 
b/arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi
new file mode 100644
index 00..c38c698794
--- /dev/null
+++ b/arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-

Re: [PATCH u-boot-marvell 00/11] Some mvebu comphy + mox + fdt_support changes

2021-11-11 Thread Marek Behún
Hello Stefan,

did you have time to look at this series?

Marek


[PATCH u-boot-marvell 09/10] arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

2021-11-11 Thread Marek Behún
From: Pali Rohár 

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on 
root bus")
Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 drivers/pci/pci-aardvark.c | 54 +-
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 8abbc3ffe8..a92f00d0af 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -202,7 +202,7 @@ struct pcie_advk {
int sec_busno;
struct udevice  *dev;
struct gpio_descreset_gpio;
-   u32 cfgcache[(0x34 - 0x10) / 4];
+   u32 cfgcache[(0x3c - 0x10) / 4];
boolcfgcrssve;
 };
 
@@ -389,20 +389,19 @@ static int pcie_advk_read_config(const struct udevice 
*bus, pci_dev_t bdf,
}
 
/*
-* The configuration space of the PCI Bridge on primary (local) bus is
+* The configuration space of the PCI Bridge on primary (first) bus is
 * not accessible via PIO transfers like all other PCIe devices. PCI
 * Bridge config registers are available directly in Aardvark memory
-* space starting at offset zero. Moreover PCI Bridge registers in the
-* range 0x10 - 0x34 are not available and register 0x38 (Expansion ROM
-* Base Address) is at offset 0x30.
-* We therefore read configuration space content of the primary PCI
-* Bridge from our virtual cache.
+* space starting at offset zero. The PCI Bridge config space is of
+* Type 0, but the BAR registers (including ROM BAR) don't have the same
+* meaning as in the PCIe specification. Therefore do not access BAR
+* registers and non-common registers (those which have different
+* meaning for Type 0 and Type 1 config space) of the primary PCI Bridge
+* and instead read their content from driver virtual cfgcache[].
 */
if (busno == pcie->first_busno) {
-   if (offset >= 0x10 && offset < 0x34)
+   if ((offset >= 0x10 && offset < 0x34) || (offset >= 0x38 && 
offset < 0x3c))
data = pcie->cfgcache[(offset - 0x10) / 4];
-   else if ((offset & ~3) == PCI_ROM_ADDRESS1)
-   data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG);
else
data = advk_readl(pcie, offset & ~3);
 
@@ -576,23 +575,22 @@ static int pcie_advk_write_config(struct udevice *bus, 
pci_dev_t bdf,
}
 
/*
-* As explained in pcie_advk_read_config(), for the configuration
-* space of the primary PCI Bridge, we write the content into virtual
-* cache.
+* As explained in pcie_advk_read_config(), PCI Bridge config registers
+* are available directly in Aardvark memory space starting at offset
+* zero. Type 1 specific registers are not available, so we write their
+* content only into driver virtual cfgcache[].
 */
if (busno == pcie->first_busno) {
-   if (offset >= 0x10 && offset < 0x34) {
+   if ((offset >= 0x10 && offset < 0x34) ||
+   (offset >= 0x38 && offset < 0x3c)) {
data = pcie->cfgcache[(offset - 0x10) / 4];
data = pci_conv_size_to_32(data, value, offset, size);
/* This PCI bridge does not have configurable bars */
if ((offset & ~3) == PCI_BASE_ADDRESS_0 ||
-   (offset & ~3) == PCI_BASE_ADDRESS_1)
+   (offset & ~3) == PCI_BASE_ADDRESS_1 ||
+   (offset & ~3) == PCI_ROM_ADDRESS1)
data = 0x0;
pcie->cfgcache[(offset - 0x10) / 4] = data;
-   } else if ((offset & ~3) == PCI_ROM_ADDRESS1) {
-   data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG);
-   data = pci_conv_size_to_32(data, value, offset, size);
-   advk_writel(pcie, data, PCIE_CORE_EXP_ROM_BAR_REG);
} else {
data = advk_readl(pcie, offset & ~3);
data = pci_conv_size_to_32(data, value, offset, size);
@@ -830,12 +828,20 @@ static int pcie_advk_setup_hw(struct pcie_advk *pcie)
 *
 * Note that this Aardvark PCI Bridge does not have a compliant Type 1
 * Configu

[PATCH u-boot-marvell 10/10] arm: mvebu: turris_mox: Remove extra newline after module topology

2021-11-11 Thread Marek Behún
From: Marek Behún 

Remove extra newline after module topology is printed.

Signed-off-by: Marek Behún 
---
 board/CZ.NIC/turris_mox/turris_mox.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 2202eb8cfb..52fa77d68c 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -607,9 +607,6 @@ int show_board_info(void)
}
}
 
-   if (module_count)
-   printf("\n");
-
return 0;
 }
 
-- 
2.32.0



[PATCH u-boot-marvell 06/10] pci: pci_mvebu: Do not allow setting ROM BAR on PCI Bridge

2021-11-11 Thread Marek Behún
From: Pali Rohár 

The PCI Bridge which represents mvebu PCIe Root Port has Expansion ROM
Base Address register at offset 0x30 but its meaning is different that
of PCI's Expansion ROM BAR register, although the address format of
the register is the same.

In reality, this device does not have any configurable PCI BARs. So
ensure that write operation into BARs (including Expansion ROM BAR) is a
noop and registers always contain zero address which indicates that BARs
are unsupported.

Fixes: a7b61ab58d5d ("pci: pci_mvebu: Properly configure and use PCI Bridge 
(PCIe Root Port)")
Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 drivers/pci/pci_mvebu.c | 55 +++--
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index b545e62689..701a17dfb7 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -93,7 +93,7 @@ struct mvebu_pcie {
unsigned int mem_attr;
unsigned int io_target;
unsigned int io_attr;
-   u32 cfgcache[(0x34 - 0x10) / 4];
+   u32 cfgcache[(0x3c - 0x10) / 4];
 };
 
 /*
@@ -189,20 +189,20 @@ static int mvebu_pcie_read_config(const struct udevice 
*bus, pci_dev_t bdf,
}
 
/*
-* mvebu has different internal registers mapped into PCI config space
-* in range 0x10-0x34 for PCI bridge, so do not access PCI config space
-* for this range and instead read content from driver virtual cfgcache
+* The configuration space of the PCI Bridge on primary (first) bus is
+* of Type 0 but the BAR registers (including ROM BAR) don't have the
+* same meaning as in the PCIe specification. Therefore do not access
+* BAR registers and non-common registers (those which have different
+* meaning for Type 0 and Type 1 config space) of the PCI Bridge and
+* instead read their content from driver virtual cfgcache[].
 */
-   if (busno == pcie->first_busno && offset >= 0x10 && offset < 0x34) {
+   if (busno == pcie->first_busno && ((offset >= 0x10 && offset < 0x34) ||
+  (offset >= 0x38 && offset < 0x3c))) {
data = pcie->cfgcache[(offset - 0x10) / 4];
debug("(addr,size,val)=(0x%04x, %d, 0x%08x) from cfgcache\n",
  offset, size, data);
*valuep = pci_conv_32_to_size(data, offset, size);
return 0;
-   } else if (busno == pcie->first_busno &&
-  (offset & ~3) == PCI_ROM_ADDRESS1) {
-   /* mvebu has Expansion ROM Base Address (0x38) at offset 0x30 */
-   offset -= PCI_ROM_ADDRESS1 - PCIE_EXP_ROM_BAR_OFF;
}
 
/*
@@ -269,17 +269,21 @@ static int mvebu_pcie_write_config(struct udevice *bus, 
pci_dev_t bdf,
}
 
/*
-* mvebu has different internal registers mapped into PCI config space
-* in range 0x10-0x34 for PCI bridge, so do not access PCI config space
-* for this range and instead write content to driver virtual cfgcache
+* As explained in mvebu_pcie_read_config(), PCI Bridge Type 1 specific
+* config registers are not available, so we write their content only
+* into driver virtual cfgcache[].
+* And as explained in mvebu_pcie_probe(), mvebu has its own specific
+* way for configuring primary and secondary bus numbers.
 */
-   if (busno == pcie->first_busno && offset >= 0x10 && offset < 0x34) {
+   if (busno == pcie->first_busno && ((offset >= 0x10 && offset < 0x34) ||
+  (offset >= 0x38 && offset < 0x3c))) {
debug("Writing to cfgcache only\n");
data = pcie->cfgcache[(offset - 0x10) / 4];
data = pci_conv_size_to_32(data, value, offset, size);
/* mvebu PCI bridge does not have configurable bars */
if ((offset & ~3) == PCI_BASE_ADDRESS_0 ||
-   (offset & ~3) == PCI_BASE_ADDRESS_1)
+   (offset & ~3) == PCI_BASE_ADDRESS_1 ||
+   (offset & ~3) == PCI_ROM_ADDRESS1)
data = 0x0;
pcie->cfgcache[(offset - 0x10) / 4] = data;
/* mvebu has its own way how to set PCI primary bus number */
@@ -297,10 +301,6 @@ static int mvebu_pcie_write_config(struct udevice *bus, 
pci_dev_t bdf,
  pcie->sec_busno);
}
return 0;
-   } else if (busno == pcie->first_busno &&
-  (offset & ~3) == PCI_ROM_ADDRESS1) {
-   /* mvebu has Expansion ROM Base Address (0x38) at offset 0x30 */
-   offset -= PCI_ROM_ADDRESS1 - PCIE_EXP_ROM_BAR_OFF;
}
 
/*
@@ -424,13 +424,20 @@ static int mvebu_pcie_probe(struct udevice *dev)
 * U-Boot cannot recognize as P2P Bridge.
 *
 * Note that this m

[PATCH u-boot-marvell 07/10] pci: pci_mvebu: Fix PCIe MEM and IO resources assignment and mbus mapping

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Do not call pci_set_region() for resources which were not properly mapped.
This prevents U-Boot to access unmapped memory space.

Update MBUS_PCI_MEM_SIZE and MBUS_PCI_IO_SIZE macros to cover all PCIe MEM
and IO ranges. Previously these macros covered only address ranges for the
first PCIe port. Between MBUS_PCI_IO_BASE and MBUS_PCI_MEM_BASE there is
space for six 128 MB long address ranges. So set MBUS_PCI_MEM_SIZE to value
of 6*128 MB. Similarly set MBUS_PCI_IO_SIZE to 6*64 KB.

Function resource_size() returns zero when start address is 0 and end
address is -1. So set invalid resources to these values to indicate that
resource has no mapping.

Split global PCIe MEM and IO resources (defined by MBUS_PCI_*_* macros)
into PCIe ports in mvebu_pcie_bind() function which allocates per-port
based struct mvebu_pcie, instead of using global state variables
mvebu_pcie_membase and mvebu_pcie_iobase. This makes pci_mvebu.c driver
independent of global static variables (which store the state of
allocation) and allows to bind and unbind the driver more times.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 arch/arm/mach-mvebu/include/mach/cpu.h |  4 +-
 drivers/pci/pci_mvebu.c| 84 ++
 2 files changed, 61 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
b/arch/arm/mach-mvebu/include/mach/cpu.h
index a7a62c7e7d..4c52a330d9 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -75,9 +75,9 @@ enum {
  * Default Device Address MAP BAR values
  */
 #define MBUS_PCI_MEM_BASE  MVEBU_SDRAM_SIZE_MAX
-#define MBUS_PCI_MEM_SIZE  (128 << 20)
+#define MBUS_PCI_MEM_SIZE  ((6*128) << 20)
 #define MBUS_PCI_IO_BASE   0xF110
-#define MBUS_PCI_IO_SIZE   (64 << 10)
+#define MBUS_PCI_IO_SIZE   ((6*64) << 10)
 #define MBUS_SPI_BASE  0xF400
 #define MBUS_SPI_SIZE  (8 << 20)
 #define MBUS_DFX_BASE  0xF600
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 701a17dfb7..fea32414bf 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -96,14 +97,6 @@ struct mvebu_pcie {
u32 cfgcache[(0x3c - 0x10) / 4];
 };
 
-/*
- * MVEBU PCIe controller needs MEMORY and I/O BARs to be mapped
- * into SoCs address space. Each controller will map 128M of MEM
- * and 64K of I/O space when registered.
- */
-static void __iomem *mvebu_pcie_membase = (void __iomem *)MBUS_PCI_MEM_BASE;
-static void __iomem *mvebu_pcie_iobase = (void __iomem *)MBUS_PCI_IO_BASE;
-
 static inline bool mvebu_pcie_link_up(struct mvebu_pcie *pcie)
 {
u32 val;
@@ -478,26 +471,24 @@ static int mvebu_pcie_probe(struct udevice *dev)
mvebu_pcie_set_local_bus_nr(pcie, 0);
mvebu_pcie_set_local_dev_nr(pcie, 1);
 
-   pcie->mem.start = (u32)mvebu_pcie_membase;
-   pcie->mem.end = pcie->mem.start + MBUS_PCI_MEM_SIZE - 1;
-   mvebu_pcie_membase += MBUS_PCI_MEM_SIZE;
-
-   if (mvebu_mbus_add_window_by_id(pcie->mem_target, pcie->mem_attr,
+   if (resource_size(&pcie->mem) &&
+   mvebu_mbus_add_window_by_id(pcie->mem_target, pcie->mem_attr,
(phys_addr_t)pcie->mem.start,
resource_size(&pcie->mem))) {
printf("PCIe unable to add mbus window for mem at %08x+%08x\n",
   (u32)pcie->mem.start, 
(unsigned)resource_size(&pcie->mem));
+   pcie->mem.start = 0;
+   pcie->mem.end = -1;
}
 
-   pcie->io.start = (u32)mvebu_pcie_iobase;
-   pcie->io.end = pcie->io.start + MBUS_PCI_IO_SIZE - 1;
-   mvebu_pcie_iobase += MBUS_PCI_IO_SIZE;
-
-   if (mvebu_mbus_add_window_by_id(pcie->io_target, pcie->io_attr,
+   if (resource_size(&pcie->io) &&
+   mvebu_mbus_add_window_by_id(pcie->io_target, pcie->io_attr,
(phys_addr_t)pcie->io.start,
resource_size(&pcie->io))) {
printf("PCIe unable to add mbus window for IO at %08x+%08x\n",
   (u32)pcie->io.start, (unsigned)resource_size(&pcie->io));
+   pcie->io.start = 0;
+   pcie->io.end = -1;
}
 
/* Setup windows and configure host bridge */
@@ -506,13 +497,23 @@ static int mvebu_pcie_probe(struct udevice *dev)
/* PCI memory space */
pci_set_region(hose->regions + 0, pcie->mem.start,
   pcie->mem.start, resource_size(&pcie->mem), 
PCI_REGION_MEM);
-   pci_set_region(hose->regions + 1,
-  0, 0,
-  gd->ram_size,
-  PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
-   pci_set_region(hose->regions + 2, pcie->io.start,
-  pcie->io.start, resource_size(&pcie->

[PATCH u-boot-marvell 08/10] pci: pci_mvebu: Remove unused DECLARE_GLOBAL_DATA_PTR

2021-11-11 Thread Marek Behún
From: Pali Rohár 

The global data pointer is not used in this driver, remove it's
declaration.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 drivers/pci/pci_mvebu.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index fea32414bf..f3830f67aa 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -28,8 +27,6 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 /* PCIe unit register offsets */
 #define SELECT(x, n)   ((x >> n) & 1UL)
 
-- 
2.32.0



[PATCH u-boot-marvell 04/10] pci: pci_mvebu: Replace MBUS_PCI_*_SIZE by resource_size()

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Use more appropriate resource_size() function when working with data in
struct resource.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 drivers/pci/pci_mvebu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 97c7b5604f..fde52ec99d 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -477,9 +477,9 @@ static int mvebu_pcie_probe(struct udevice *dev)
 
if (mvebu_mbus_add_window_by_id(pcie->mem_target, pcie->mem_attr,
(phys_addr_t)pcie->mem.start,
-   MBUS_PCI_MEM_SIZE)) {
+   resource_size(&pcie->mem))) {
printf("PCIe unable to add mbus window for mem at %08x+%08x\n",
-  (u32)pcie->mem.start, MBUS_PCI_MEM_SIZE);
+  (u32)pcie->mem.start, 
(unsigned)resource_size(&pcie->mem));
}
 
pcie->io.start = (u32)mvebu_pcie_iobase;
@@ -488,9 +488,9 @@ static int mvebu_pcie_probe(struct udevice *dev)
 
if (mvebu_mbus_add_window_by_id(pcie->io_target, pcie->io_attr,
(phys_addr_t)pcie->io.start,
-   MBUS_PCI_IO_SIZE)) {
+   resource_size(&pcie->io))) {
printf("PCIe unable to add mbus window for IO at %08x+%08x\n",
-  (u32)pcie->io.start, MBUS_PCI_IO_SIZE);
+  (u32)pcie->io.start, (unsigned)resource_size(&pcie->io));
}
 
/* Setup windows and configure host bridge */
@@ -498,13 +498,13 @@ static int mvebu_pcie_probe(struct udevice *dev)
 
/* PCI memory space */
pci_set_region(hose->regions + 0, pcie->mem.start,
-  pcie->mem.start, MBUS_PCI_MEM_SIZE, PCI_REGION_MEM);
+  pcie->mem.start, resource_size(&pcie->mem), 
PCI_REGION_MEM);
pci_set_region(hose->regions + 1,
   0, 0,
   gd->ram_size,
   PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
pci_set_region(hose->regions + 2, pcie->io.start,
-  pcie->io.start, MBUS_PCI_IO_SIZE, PCI_REGION_IO);
+  pcie->io.start, resource_size(&pcie->io), PCI_REGION_IO);
hose->region_count = 3;
 
/* PCI Bridge support 32-bit I/O and 64-bit prefetch mem addressing */
-- 
2.32.0



[PATCH u-boot-marvell 05/10] pci: pci_mvebu, pci_aardvark: Fix size of configuration cache

2021-11-11 Thread Marek Behún
From: Marek Behún 

Since u32 takes up 4 bytes, we need to divide the number of u32s by 4
for cfgcache.

Signed-off-by: Marek Behún 
---
 drivers/pci/pci-aardvark.c | 2 +-
 drivers/pci/pci_mvebu.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 4e94b776c5..8abbc3ffe8 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -202,7 +202,7 @@ struct pcie_advk {
int sec_busno;
struct udevice  *dev;
struct gpio_descreset_gpio;
-   u32 cfgcache[0x34 - 0x10];
+   u32 cfgcache[(0x34 - 0x10) / 4];
boolcfgcrssve;
 };
 
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index fde52ec99d..b545e62689 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -93,7 +93,7 @@ struct mvebu_pcie {
unsigned int mem_attr;
unsigned int io_target;
unsigned int io_attr;
-   u32 cfgcache[0x34 - 0x10];
+   u32 cfgcache[(0x34 - 0x10) / 4];
 };
 
 /*
-- 
2.32.0



[PATCH u-boot-marvell 02/10] arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c

2021-11-11 Thread Marek Behún
From: Pali Rohár 

As explained in commit 3bedbcc3aa18 ("arm: mvebu: a38x: serdes: Don't
overwrite read-only SAR PCIe registers") it is required to set Maximum Link
Width bits of PCIe Root Port Link Capabilities Register depending of number
of used serdes lanes. As this register is part of PCIe address space and
not serdes address space, move it into pci_mvebu.c driver.

Read number of PCIe lanes from DT propery "num-lanes" which is used also by
other PCIe controller drivers in Linux kernel. If this property is absent.
default to 1. This property needs to be set to 4 for every mvebu board
which use PEX_ROOT_COMPLEX_X4. Currently in U-Boot there is no such board.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h |  4 
 .../serdes/a38x/high_speed_env_spec.c  | 15 ---
 drivers/pci/pci_mvebu.c| 18 ++
 3 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h 
b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
index 64193d5288..0df898c625 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
@@ -6,12 +6,8 @@
 #ifndef _CTRL_PEX_H
 #define _CTRL_PEX_H
 
-#include 
 #include "high_speed_env_spec.h"
 
-/* Direct access to PEX0 Root Port's PCIe Capability structure */
-#define PEX0_RP_PCIE_CFG_OFFSET(0x0008 + 0x60)
-
 /* SOC_CONTROL_REG1 fields */
 #define PCIE0_ENABLE_OFFS  0
 #define PCIE0_ENABLE_MASK  (0x1 << PCIE0_ENABLE_OFFS)
diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c 
b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index d2bc3ab25c..ef4b89c96a 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -1720,21 +1720,6 @@ int serdes_power_up_ctrl(u32 serdes_num, int 
serdes_power_up,
else
reg_data &= ~0x4000;
reg_write(SOC_CONTROL_REG1, reg_data);
-
-   /*
-* Set Maximum Link Width to X1 or X4 in Root
-* Port's PCIe Link Capability register.
-* This register is read-only but if is not set
-* correctly then access to PCI config space of
-* endpoint card behind this Root Port does not
-* work.
-*/
-   reg_data = reg_read(PEX0_RP_PCIE_CFG_OFFSET +
-   PCI_EXP_LNKCAP);
-   reg_data &= ~PCI_EXP_LNKCAP_MLW;
-   reg_data |= (is_pex_by1 ? 1 : 4) << 4;
-   reg_write(PEX0_RP_PCIE_CFG_OFFSET +
- PCI_EXP_LNKCAP, reg_data);
}
 
CHECK_STATUS(mv_seq_exec(serdes_num, PEX_POWER_UP_SEQ));
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index a3364d5a59..278dc2756f 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -83,6 +83,7 @@ struct mvebu_pcie {
struct resource io;
u32 port;
u32 lane;
+   bool is_x4;
int devfn;
u32 lane_mask;
int first_busno;
@@ -399,6 +400,18 @@ static int mvebu_pcie_probe(struct udevice *dev)
reg |= PCIE_CTRL_RC_MODE;
writel(reg, pcie->base + PCIE_CTRL_OFF);
 
+   /*
+* Set Maximum Link Width to X1 or X4 in Root Port's PCIe Link
+* Capability register. This register is defined by PCIe specification
+* as read-only but this mvebu controller has it as read-write and must
+* be set to number of SerDes PCIe lanes (1 or 4). If this register is
+* not set correctly then link with endpoint card is not established.
+*/
+   reg = readl(pcie->base + PCIE_CAPAB_OFF + PCI_EXP_LNKCAP);
+   reg &= ~PCI_EXP_LNKCAP_MLW;
+   reg |= (pcie->is_x4 ? 4 : 1) << 4;
+   writel(reg, pcie->base + PCIE_CAPAB_OFF + PCI_EXP_LNKCAP);
+
/*
 * Change Class Code of PCI Bridge device to PCI Bridge (0x600400)
 * because default value is Memory controller (0x508000) which
@@ -582,6 +595,7 @@ static int mvebu_get_tgt_attr(ofnode node, int devfn,
 static int mvebu_pcie_of_to_plat(struct udevice *dev)
 {
struct mvebu_pcie *pcie = dev_get_plat(dev);
+   u32 num_lanes = 1;
int ret = 0;
 
/* Get port number, lane number and memory target / attr */
@@ -594,6 +608,10 @@ static int mvebu_pcie_of_to_plat(struct udevice *dev)
if (ofnode_read_u32(dev_ofnode(dev), "marvell,pcie-lane", &pcie->lane))
pcie->lane = 0;
 
+   if (!ofnode_read_u32(dev_ofnode(dev), "nu

[PATCH u-boot-marvell 03/10] pci: pci_mvebu: Move setup for BAR[0] where other BARs are setup

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Function mvebu_pcie_setup_wins() sets up all other BARs, so move setup of
BAR[0] to this function to have common code at one place.

In the past, commit 193a1e9f196b ("pci: pci_mvebu: set BAR0 after memory
space is set") moved setup of BAR[0] to another location, due to ath10k
not working in kernel, but the reason why was unknown, but it seems to
work now, and we think the issue then was cause by the PCIe Root Port
presenting itself as a Memory Controller and therefore U-Boot's code
have overwritten the BAR. Since the driver now ignores any write
operations to PCIe Root Port BARs, this should not be an issue anymore.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 drivers/pci/pci_mvebu.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 278dc2756f..97c7b5604f 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -335,7 +335,9 @@ static int mvebu_pcie_write_config(struct udevice *bus, 
pci_dev_t bdf,
 
 /*
  * Setup PCIE BARs and Address Decode Wins:
- * BAR[0,2] -> disabled, BAR[1] -> covers all DRAM banks
+ * BAR[0] -> internal registers
+ * BAR[1] -> covers all DRAM banks
+ * BAR[2] -> disabled
  * WIN[0-3] -> DRAM bank[0-3]
  */
 static void mvebu_pcie_setup_wins(struct mvebu_pcie *pcie)
@@ -386,6 +388,10 @@ static void mvebu_pcie_setup_wins(struct mvebu_pcie *pcie)
writel(0, pcie->base + PCIE_BAR_HI_OFF(1));
writel(((size - 1) & 0x) | 0x1,
   pcie->base + PCIE_BAR_CTRL_OFF(1));
+
+   /* Setup BAR[0] to internal registers. */
+   writel(SOC_REGS_PHY_BASE, pcie->base + PCIE_BAR_LO_OFF(0));
+   writel(0, pcie->base + PCIE_BAR_HI_OFF(0));
 }
 
 static int mvebu_pcie_probe(struct udevice *dev)
@@ -501,10 +507,6 @@ static int mvebu_pcie_probe(struct udevice *dev)
   pcie->io.start, MBUS_PCI_IO_SIZE, PCI_REGION_IO);
hose->region_count = 3;
 
-   /* Set BAR0 to internal registers */
-   writel(SOC_REGS_PHY_BASE, pcie->base + PCIE_BAR_LO_OFF(0));
-   writel(0, pcie->base + PCIE_BAR_HI_OFF(0));
-
/* PCI Bridge support 32-bit I/O and 64-bit prefetch mem addressing */
pcie->cfgcache[(PCI_IO_BASE - 0x10) / 4] =
PCI_IO_RANGE_TYPE_32 | (PCI_IO_RANGE_TYPE_32 << 8);
-- 
2.32.0



[PATCH u-boot-marvell 01/10] pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe()

2021-11-11 Thread Marek Behún
From: Pali Rohár 

Function mvebu_pcie_probe() configures PCIe controller and sometimes it
takes some time for PCIe card to bring link up. Delay mvebu_pcie_probe()
for 100ms to ensure that PCIe link is up after function finish. In the
case when no card is connected to the PCIe slot, this will delay probe
time by 100ms, which should not be problematic.

This change fixes detection and initialization of some QCA98xx cards on
the first serdes when configured in x1 mode. Default configuration of
the first serdes on A385 is x4 mode, so it looks as if some delay is
required when x4 is changed to x1 and card correctly links with A385.
Other PCIe serdes ports on A385 are x1-only, and so they don't have this
problem.

(We need this patch because in the following patch we are moving the
 configuration change from x4 to x1 from serdes driver to PCIe mvebu
 driver, because the corresponding register lives in the address space
 of the PCIe controller. Without that this explicit timeout is not
 needed, because there is an implicit timeout between change from x4 to
 x1 and probe of PCIe mvebu driver, due to the first being run in SPL
 and the second in U-Boot proper.)

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 drivers/pci/pci_mvebu.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 14cd82db6f..a3364d5a59 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -70,6 +71,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #define PCIE_DEBUG_CTRL0x1a60
 #define  PCIE_DEBUG_SOFT_RESET BIT(20)
 
+#define LINK_WAIT_RETRIES  100
+#define LINK_WAIT_TIMEOUT  1000
+
 struct mvebu_pcie {
struct pci_controller hose;
void __iomem *base;
@@ -106,6 +110,23 @@ static inline bool mvebu_pcie_link_up(struct mvebu_pcie 
*pcie)
return !(val & PCIE_STAT_LINK_DOWN);
 }
 
+static void mvebu_pcie_wait_for_link(struct mvebu_pcie *pcie)
+{
+   int retries;
+
+   /* check if the link is up or not */
+   for (retries = 0; retries < LINK_WAIT_RETRIES; retries++) {
+   if (mvebu_pcie_link_up(pcie)) {
+   printf("%s: Link up\n", pcie->name);
+   return;
+   }
+
+   udelay(LINK_WAIT_TIMEOUT);
+   }
+
+   printf("%s: Link down\n", pcie->name);
+}
+
 static void mvebu_pcie_set_local_bus_nr(struct mvebu_pcie *pcie, int busno)
 {
u32 stat;
@@ -477,6 +498,8 @@ static int mvebu_pcie_probe(struct udevice *dev)
pcie->cfgcache[(PCI_PREF_MEMORY_BASE - 0x10) / 4] =
PCI_PREF_RANGE_TYPE_64 | (PCI_PREF_RANGE_TYPE_64 << 16);
 
+   mvebu_pcie_wait_for_link(pcie);
+
return 0;
 }
 
-- 
2.32.0



[PATCH u-boot-marvell 00/10] PCI mvebu and aardvark changes

2021-11-11 Thread Marek Behún
From: Marek Behún 

Hello Stefan,

we have some more fixes for PCI (mvebu and aardvark), and one patch
for Turris MOX board code.

Marek

Marek Behún (2):
  pci: pci_mvebu, pci_aardvark: Fix size of configuration cache
  arm: mvebu: turris_mox: Remove extra newline after module topology

Pali Rohár (8):
  pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe()
  arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c
  pci: pci_mvebu: Move setup for BAR[0] where other BARs are setup
  pci: pci_mvebu: Replace MBUS_PCI_*_SIZE by resource_size()
  pci: pci_mvebu: Do not allow setting ROM BAR on PCI Bridge
  pci: pci_mvebu: Fix PCIe MEM and IO resources assignment and mbus
mapping
  pci: pci_mvebu: Remove unused DECLARE_GLOBAL_DATA_PTR
  arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

 arch/arm/mach-mvebu/include/mach/cpu.h|   4 +-
 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h|   4 -
 .../serdes/a38x/high_speed_env_spec.c |  15 --
 board/CZ.NIC/turris_mox/turris_mox.c  |   3 -
 drivers/pci/pci-aardvark.c|  54 +++--
 drivers/pci/pci_mvebu.c   | 205 --
 6 files changed, 175 insertions(+), 110 deletions(-)

-- 
2.32.0



Re: [v2, PATCH] lib: sparse: Make CHUNK_TYPE_RAW buffer aligned

2021-11-11 Thread Sean Anderson




On 11/7/21 9:29 PM, qianfangui...@qq.com wrote:

From: qianfan Zhao 

CHUNK_TYPE_RAW buffer is not aligned, and flash sparse images by
fastboot will report "Misaligned operation" if DCACHE is enabled.

Flashing Sparse Image
CACHE: Misaligned operation at range [8428, 84001028]
CACHE: Misaligned operation at range [84001034, 84002034]
CACHE: Misaligned operation at range [8401104c, 8401304c]

Fix it

Signed-off-by: qianfan Zhao 
---
  lib/image-sparse.c | 39 ++-
  1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/lib/image-sparse.c b/lib/image-sparse.c
index d80fdbbf58..07aa3dd6ba 100644
--- a/lib/image-sparse.c
+++ b/lib/image-sparse.c
@@ -49,6 +49,41 @@
  
  static void default_log(const char *ignored, char *response) {}
  
+static lbaint_t write_sparse_chunk_raw(struct sparse_storage *info,

+  lbaint_t blk, lbaint_t blkcnt,
+  void *data,
+  char *response)
+{
+   lbaint_t n, write_blks, blks = 0, aligned_buf_blks = 100;
+   uint32_t *aligned_buf = NULL;
+
+   if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF))
+   return info->write(info, blk, blkcnt, data);
+
+   aligned_buf = memalign(ARCH_DMA_MINALIGN, info->blksz * 
aligned_buf_blks);
+   if (!aligned_buf) {
+   info->mssg("Malloc failed for: CHUNK_TYPE_RAW", response);
+   return -ENOMEM;
+   }
+
+   while (blkcnt > 0) {
+   n = min(aligned_buf_blks, blkcnt);
+   memcpy(aligned_buf, data, n * info->blksz);
+
+   /* write_blks might be > n due to NAND bad-blocks */
+   write_blks = info->write(info, blk + blks, n, aligned_buf);
+   blks += write_blks;
+   if (write_blks < n)
+   break;
+
+   data += n * info->blksz;
+   blkcnt -= n;
+   }
+
+   free(aligned_buf);
+   return blks;
+}
+
  int write_sparse_image(struct sparse_storage *info,
   const char *part_name, void *data, char *response)
  {
@@ -152,7 +187,9 @@ int write_sparse_image(struct sparse_storage *info,
return -1;
}
  
-			blks = info->write(info, blk, blkcnt, data);

+   blks = write_sparse_chunk_raw(info, blk, blkcnt,
+ data, response);
+
/* blks might be > blkcnt (eg. NAND bad-blocks) */
if (blks < blkcnt) {
printf("%s: %s" LBAFU " [" LBAFU "]\n",


The rest of the patch looks good, but the error check here still need to be 
updated. It should be something like

if (IS_ERR_VALUE(blks)) {
printf("%s: Write failed (error %lld)", 
__func__, blks);
info->mssg(...);
return blks;
} else if (blks < blkcnt) {
printf("%s: Write failed, block #" LBAFU " [" LBAFU 
"]\n",

}

--Sean


Re: [RFC 0/2] Do not stop with an error when mkimage fails

2021-11-11 Thread Tom Rini
On Thu, Nov 11, 2021 at 01:27:22PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20211109194224.GB24579@bill-the-cat> you wrote:
> > 
> > > The only reason I want to introduce this is because I want to have my
> > > imx8mq board built by CI. This board needs an external HDMI firmware
> > > which is used by mkimage. But because this firmware is not available
> > > in the CI build, it comes to the abort. With other boards it is also
> > > so that in the CI external blobs are not available and these make
> > > nevertheless without error a binman run. In this case only a warning
> > > is output.
> ...
> > Unfortunately in these days of needing multiple inputs to create a
> > functional image and also needing to have CI be able to be at all
> > useful, what we do in many many many cases is yell loudly to the user
> > that the resulting file here will NOT work and why.  So yes, some "yell
> > it won't work but not return non-zero exit status" is the norm.
> 
> This is a terrible degradtion from standard programming style, then.

Yes, there's a lot of things to grumble about with firmware for modern
SoCs.

> > I would be very much open however to some way to handle this
> > differently.  Some environment variable our tools check for and then
> > yell-but-succeed?  Some other idea?  I'm just thinking out loud here.
> 
> Well, why not fix the root cause?
> 
> Heiko writes that "an external HDMI firmware" is needed - so the fix
> is to provide one, or at least a dummy file which is good enough for
> the build to succeed.  It should be trivial to create a dummy file
> in the CI context, no?

Yes, generally we provide some dummy file so that we can link and
complain to stdout that things won't function.  This series is (and it
seems like within the confines of "this sucks to have to do as a
concept") updating that mechanism to cover yet another case where we
need some external blob that we either can't redistribute or it would
just be wrong to fork and include some other project within our sources.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V3 5/5] doc: imx8mq_evk: update doc after using binman

2021-11-11 Thread Patrick Wildt
On Fri, Oct 22, 2021 at 10:42:20AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Update doc after using binman to pack images

Not necessary if we make sure flash.bin stays a single bootable image

> Signed-off-by: Peng Fan 
> ---
>  doc/board/nxp/imx8mq_evk.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/board/nxp/imx8mq_evk.rst b/doc/board/nxp/imx8mq_evk.rst
> index c269fdebe3..92eeda79aa 100644
> --- a/doc/board/nxp/imx8mq_evk.rst
> +++ b/doc/board/nxp/imx8mq_evk.rst
> @@ -43,13 +43,14 @@ Build U-Boot
>  
> $ export CROSS_COMPILE=aarch64-poky-linux-
> $ make imx8mq_evk_defconfig
> -   $ make flash.bin
> +   $ make
>  
>  Burn the flash.bin to MicroSD card offset 33KB:
>  
>  .. code-block:: bash
>  
> $sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=notrunc
> +   $sudo dd if=u-boot.itb of=/dev/sd[x] bs=1024 seek=384 conv=notrunc
>  
>  Boot
>  
> -- 
> 2.30.0
> 


Re: [PATCH V3 4/5] imx: imx8mq use common imximage.cfg

2021-11-11 Thread Patrick Wildt
On Fri, Oct 22, 2021 at 10:42:19AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> After all these board switch to binman, we could use common imximage.cfg

Reviewed-by: Patrick Wildt 

> Signed-off-by: Peng Fan 
> ---
>  arch/arm/mach-imx/imx8m/imximage.cfg  | 12 +++-
>  board/freescale/imx8mq_evk/Kconfig|  2 +-
>  board/freescale/imx8mq_evk/imximage.cfg   | 11 ---
>  board/google/imx8mq_phanbell/Kconfig  |  2 +-
>  board/google/imx8mq_phanbell/imximage.cfg | 11 ---
>  board/technexion/pico-imx8mq/Kconfig  |  2 +-
>  board/technexion/pico-imx8mq/imximage.cfg | 11 ---
>  7 files changed, 6 insertions(+), 45 deletions(-)
>  delete mode 100644 board/freescale/imx8mq_evk/imximage.cfg
>  delete mode 100644 board/google/imx8mq_phanbell/imximage.cfg
>  delete mode 100644 board/technexion/pico-imx8mq/imximage.cfg
> 
> diff --git a/arch/arm/mach-imx/imx8m/imximage.cfg 
> b/arch/arm/mach-imx/imx8m/imximage.cfg
> index 714b24273b..9c6eaf0a6d 100644
> --- a/arch/arm/mach-imx/imx8m/imximage.cfg
> +++ b/arch/arm/mach-imx/imx8m/imximage.cfg
> @@ -1,17 +1,11 @@
>  /* SPDX-License-Identifier: GPL-2.0+ */
>  /*
> - * Copyright 2018 NXP
> + * Copyright 2018-2021 NXP
>   */
>  
>  #define __ASSEMBLY__
>  
>  FIT
>  BOOT_FROMsd
> -SIGNED_HDMI  signed_hdmi_imx8m.bin
> -LOADER   spl/u-boot-spl-ddr.bin  0x7E1000
> -SECOND_LOADERu-boot.itb  0x4020 0x6
> -
> -DDR_FW lpddr4_pmu_train_1d_imem.bin
> -DDR_FW lpddr4_pmu_train_1d_dmem.bin
> -DDR_FW lpddr4_pmu_train_2d_imem.bin
> -DDR_FW lpddr4_pmu_train_2d_dmem.bin
> +SIGNED_HDMI  signed_hdmi.bin
> +LOADER   mkimage.flash.mkimage   0x7e1000
> diff --git a/board/freescale/imx8mq_evk/Kconfig 
> b/board/freescale/imx8mq_evk/Kconfig
> index a7c49744b3..c4d20ad7c7 100644
> --- a/board/freescale/imx8mq_evk/Kconfig
> +++ b/board/freescale/imx8mq_evk/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
>   default "imx8mq_evk"
>  
>  config IMX_CONFIG
> - default "board/freescale/imx8mq_evk/imximage.cfg"
> + default "arch/arm/mach-imx/imx8m/imximage.cfg"
>  
>  endif
> diff --git a/board/freescale/imx8mq_evk/imximage.cfg 
> b/board/freescale/imx8mq_evk/imximage.cfg
> deleted file mode 100644
> index 74f12b30d2..00
> --- a/board/freescale/imx8mq_evk/imximage.cfg
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright 2021 NXP
> - */
> -
> -#define __ASSEMBLY__
> -
> -FIT
> -BOOT_FROMsd
> -SIGNED_HDMI  signed_hdmi.bin
> -LOADER   mkimage.flash.mkimage   0x7e1000
> diff --git a/board/google/imx8mq_phanbell/Kconfig 
> b/board/google/imx8mq_phanbell/Kconfig
> index e59b03cb17..54cfb99952 100644
> --- a/board/google/imx8mq_phanbell/Kconfig
> +++ b/board/google/imx8mq_phanbell/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
>   default "imx8mq_phanbell"
>  
>  config IMX_CONFIG
> - default "board/google/imx8mq_phanbell/imximage.cfg"
> + default "arch/arm/mach-imx/imx8m/imximage.cfg"
>  
>  endif
> diff --git a/board/google/imx8mq_phanbell/imximage.cfg 
> b/board/google/imx8mq_phanbell/imximage.cfg
> deleted file mode 100644
> index 74f12b30d2..00
> --- a/board/google/imx8mq_phanbell/imximage.cfg
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright 2021 NXP
> - */
> -
> -#define __ASSEMBLY__
> -
> -FIT
> -BOOT_FROMsd
> -SIGNED_HDMI  signed_hdmi.bin
> -LOADER   mkimage.flash.mkimage   0x7e1000
> diff --git a/board/technexion/pico-imx8mq/Kconfig 
> b/board/technexion/pico-imx8mq/Kconfig
> index 97655517d8..628b051149 100644
> --- a/board/technexion/pico-imx8mq/Kconfig
> +++ b/board/technexion/pico-imx8mq/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
>   default "pico-imx8mq"
>  
>  config IMX_CONFIG
> - default "board/technexion/pico-imx8mq/imximage.cfg"
> + default "arch/arm/mach-imx/imx8m/imximage.cfg"
>  
>  endif
> diff --git a/board/technexion/pico-imx8mq/imximage.cfg 
> b/board/technexion/pico-imx8mq/imximage.cfg
> deleted file mode 100644
> index 74f12b30d2..00
> --- a/board/technexion/pico-imx8mq/imximage.cfg
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright 2021 NXP
> - */
> -
> -#define __ASSEMBLY__
> -
> -FIT
> -BOOT_FROMsd
> -SIGNED_HDMI  signed_hdmi.bin
> -LOADER   mkimage.flash.mkimage   0x7e1000
> -- 
> 2.30.0
> 


Re: [PATCH V3 3/5] imx: pico-imx8mq: switch to use binman

2021-11-11 Thread Patrick Wildt
On Fri, Oct 22, 2021 at 10:42:18AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Switch to use binman to pack images

Reviewed-by: Patrick Wildt 

> Signed-off-by: Peng Fan 
> ---
>  arch/arm/dts/imx8mq-pico-pi.dts   |  1 +
>  arch/arm/mach-imx/imx8m/Kconfig   |  1 +
>  board/technexion/pico-imx8mq/Kconfig  |  2 +-
>  board/technexion/pico-imx8mq/imximage.cfg | 11 +++
>  configs/pico-imx8mq_defconfig |  2 +-
>  5 files changed, 15 insertions(+), 2 deletions(-)
>  create mode 100644 board/technexion/pico-imx8mq/imximage.cfg
> 
> diff --git a/arch/arm/dts/imx8mq-pico-pi.dts b/arch/arm/dts/imx8mq-pico-pi.dts
> index d2af18ad0e..8ed6e9166b 100644
> --- a/arch/arm/dts/imx8mq-pico-pi.dts
> +++ b/arch/arm/dts/imx8mq-pico-pi.dts
> @@ -9,6 +9,7 @@
>  /dts-v1/;
>  
>  #include "imx8mq.dtsi"
> +#include "imx8mq-u-boot.dtsi"
>  
>  / {
>   model = "TechNexion PICO-PI-8M";
> diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
> index b453e5a7da..707d2d5f4b 100644
> --- a/arch/arm/mach-imx/imx8m/Kconfig
> +++ b/arch/arm/mach-imx/imx8m/Kconfig
> @@ -107,6 +107,7 @@ config TARGET_IMX8MP_EVK
>  
>  config TARGET_PICO_IMX8MQ
>   bool "Support Technexion Pico iMX8MQ"
> + select BINMAN
>   select IMX8MQ
>   select IMX8M_LPDDR4
>  
> diff --git a/board/technexion/pico-imx8mq/Kconfig 
> b/board/technexion/pico-imx8mq/Kconfig
> index 628b051149..97655517d8 100644
> --- a/board/technexion/pico-imx8mq/Kconfig
> +++ b/board/technexion/pico-imx8mq/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
>   default "pico-imx8mq"
>  
>  config IMX_CONFIG
> - default "arch/arm/mach-imx/imx8m/imximage.cfg"
> + default "board/technexion/pico-imx8mq/imximage.cfg"
>  
>  endif
> diff --git a/board/technexion/pico-imx8mq/imximage.cfg 
> b/board/technexion/pico-imx8mq/imximage.cfg
> new file mode 100644
> index 00..74f12b30d2
> --- /dev/null
> +++ b/board/technexion/pico-imx8mq/imximage.cfg
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#define __ASSEMBLY__
> +
> +FIT
> +BOOT_FROMsd
> +SIGNED_HDMI  signed_hdmi.bin
> +LOADER   mkimage.flash.mkimage   0x7e1000
> diff --git a/configs/pico-imx8mq_defconfig b/configs/pico-imx8mq_defconfig
> index b90a492424..a25baf71dc 100644
> --- a/configs/pico-imx8mq_defconfig
> +++ b/configs/pico-imx8mq_defconfig
> @@ -17,7 +17,7 @@ CONFIG_SYS_LOAD_ADDR=0x4048
>  CONFIG_FIT=y
>  CONFIG_FIT_EXTERNAL_OFFSET=0x3000
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
> +# CONFIG_USE_SPL_FIT_GENERATOR is not set
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_BOARD_LATE_INIT=y
>  CONFIG_SPL_BOARD_INIT=y
> -- 
> 2.30.0
> 


Re: [PATCH V3 2/5] imx: imx8mq_phanbell: switch to binman

2021-11-11 Thread Patrick Wildt
On Fri, Oct 22, 2021 at 10:42:17AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Switch to binman to pack images

Reviewed-by: Patrick Wildt 

> Signed-off-by: Peng Fan 
> ---
>  arch/arm/dts/imx8mq-phanbell-u-boot.dtsi  |  2 ++
>  arch/arm/mach-imx/imx8m/Kconfig   |  7 ---
>  board/google/imx8mq_phanbell/Kconfig  |  2 +-
>  board/google/imx8mq_phanbell/imximage.cfg | 11 +++
>  configs/imx8mq_phanbell_defconfig |  2 +-
>  5 files changed, 19 insertions(+), 5 deletions(-)
>  create mode 100644 board/google/imx8mq_phanbell/imximage.cfg
> 
> diff --git a/arch/arm/dts/imx8mq-phanbell-u-boot.dtsi 
> b/arch/arm/dts/imx8mq-phanbell-u-boot.dtsi
> index 4712cf6a44..a65a942ee7 100644
> --- a/arch/arm/dts/imx8mq-phanbell-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-phanbell-u-boot.dtsi
> @@ -1,5 +1,7 @@
>  // SPDX-License-Identifier: (GPL-2.0 OR MIT)
>  
> +#include "imx8mq-u-boot.dtsi"
> +
>  ®_usdhc2_vmmc {
>   u-boot,off-on-delay-us = <2>;
>  };
> diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
> index c556e712b7..b453e5a7da 100644
> --- a/arch/arm/mach-imx/imx8m/Kconfig
> +++ b/arch/arm/mach-imx/imx8m/Kconfig
> @@ -41,9 +41,10 @@ config TARGET_IMX8MQ_EVK
>   select IMX8M_LPDDR4
>  
>  config TARGET_IMX8MQ_PHANBELL
> -bool "imx8mq_phanbell"
> -select IMX8MQ
> -select IMX8M_LPDDR4
> + bool "imx8mq_phanbell"
> + select BINMAN
> + select IMX8MQ
> + select IMX8M_LPDDR4
>  
>  config TARGET_IMX8MM_EVK
>   bool "imx8mm LPDDR4 EVK board"
> diff --git a/board/google/imx8mq_phanbell/Kconfig 
> b/board/google/imx8mq_phanbell/Kconfig
> index 54cfb99952..e59b03cb17 100644
> --- a/board/google/imx8mq_phanbell/Kconfig
> +++ b/board/google/imx8mq_phanbell/Kconfig
> @@ -10,6 +10,6 @@ config SYS_CONFIG_NAME
>   default "imx8mq_phanbell"
>  
>  config IMX_CONFIG
> - default "arch/arm/mach-imx/imx8m/imximage.cfg"
> + default "board/google/imx8mq_phanbell/imximage.cfg"
>  
>  endif
> diff --git a/board/google/imx8mq_phanbell/imximage.cfg 
> b/board/google/imx8mq_phanbell/imximage.cfg
> new file mode 100644
> index 00..74f12b30d2
> --- /dev/null
> +++ b/board/google/imx8mq_phanbell/imximage.cfg
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#define __ASSEMBLY__
> +
> +FIT
> +BOOT_FROMsd
> +SIGNED_HDMI  signed_hdmi.bin
> +LOADER   mkimage.flash.mkimage   0x7e1000
> diff --git a/configs/imx8mq_phanbell_defconfig 
> b/configs/imx8mq_phanbell_defconfig
> index 911c3391db..a8eab85b4a 100644
> --- a/configs/imx8mq_phanbell_defconfig
> +++ b/configs/imx8mq_phanbell_defconfig
> @@ -18,7 +18,7 @@ CONFIG_SYS_LOAD_ADDR=0x4048
>  CONFIG_FIT=y
>  CONFIG_FIT_EXTERNAL_OFFSET=0x3000
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
> +# CONFIG_USE_SPL_FIT_GENERATOR is not set
>  CONFIG_SD_BOOT=y
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_BOARD_INIT=y
> -- 
> 2.30.0
> 


Re: [PATCH V3 1/5] imx: imx8mq_evk: switch to binman

2021-11-11 Thread Patrick Wildt
On Fri, Oct 22, 2021 at 10:42:16AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Switch to use binman to pack images
> 
> Signed-off-by: Peng Fan 

I'm unsure how to reply to this.  On the one hand I really like to see
this go in, on the other hand this changes the expectation of what
flash.bin is.  We had the same discussion for i.MX8MM.

Because historically, flash.bin is SPL+U-Boot.itb, and for i.MX8MM
people have changed the binman config to generate a single bootable
file again: 028abfd9b1576b45cf756b9a0c978cfe17906314

So, I would ask you to adjust the imx8mq-u-boot.dts changes in the same
way as done for i.MX8MM.  You should be able to see the differences
by diffing e.g. these files:

diff -u arch/arm/dts/imx8mq-u-boot.dtsi arch/arm/dts/imx8mm-evk-u-boot.dtsi

> ---
>  arch/arm/dts/imx8mq-evk-u-boot.dtsi |   2 +
>  arch/arm/dts/imx8mq-u-boot.dtsi | 122 
>  arch/arm/mach-imx/imx8m/Kconfig |   1 +
>  board/freescale/imx8mq_evk/Kconfig  |   2 +-
>  board/freescale/imx8mq_evk/imximage.cfg |  11 +++
>  configs/imx8mq_evk_defconfig|   2 +-
>  6 files changed, 138 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/dts/imx8mq-u-boot.dtsi
>  create mode 100644 board/freescale/imx8mq_evk/imximage.cfg
> 
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi 
> b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> index 2cfc12b7e0..6f9c81462e 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -1,5 +1,7 @@
>  // SPDX-License-Identifier: (GPL-2.0 OR MIT)
>  
> +#include "imx8mq-u-boot.dtsi"
> +
>  &usdhc1 {
>   mmc-hs400-1_8v;
>  };
> diff --git a/arch/arm/dts/imx8mq-u-boot.dtsi b/arch/arm/dts/imx8mq-u-boot.dtsi
> new file mode 100644
> index 00..2c10e9b645
> --- /dev/null
> +++ b/arch/arm/dts/imx8mq-u-boot.dtsi
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +
> +};
> +
> +&binman {
> + u-boot-spl-ddr {
> + filename = "u-boot-spl-ddr.bin";
> + pad-byte = <0xff>;
> + align-size = <4>;
> + align = <4>;
> +
> + u-boot-spl {
> + align-end = <4>;
> + };
> +
> + blob_1: blob-ext@1 {
> + filename = "lpddr4_pmu_train_1d_imem.bin";
> + size = <0x8000>;
> + };
> +
> + blob_2: blob-ext@2 {
> + filename = "lpddr4_pmu_train_1d_dmem.bin";
> + size = <0x4000>;
> + };
> +
> + blob_3: blob-ext@3 {
> + filename = "lpddr4_pmu_train_2d_imem.bin";
> + size = <0x8000>;
> + };
> +
> + blob_4: blob-ext@4 {
> + filename = "lpddr4_pmu_train_2d_dmem.bin";
> + size = <0x4000>;
> + };
> + };
> +
> + signed_hdmi {
> + filename = "signed_hdmi.bin";
> +
> + blob_5: blob-ext@5 {
> + filename = "signed_hdmi_imx8m.bin";
> + };
> + };
> +
> + flash {
> + mkimage {
> + args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
> 0x7e1000";
> +
> + blob {
> + filename = "u-boot-spl-ddr.bin";
> + };
> +
> + };
> +
> + };
> +
> + itb {
> + filename = "u-boot.itb";
> +
> + fit {
> + description = "Configuration to load ATF before U-Boot";
> + #address-cells = <1>;
> + fit,external-offset = ;
> +
> + images {
> + uboot {
> + description = "U-Boot (64-bit)";
> + type = "standalone";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> +
> + uboot_blob: blob-ext {
> + filename = "u-boot-nodtb.bin";
> + };
> + };
> +
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + load = <0x91>;
> + entry = <0x91>;
> +
> + atf_blob: blob-ext {
> + filename = "bl31.bin";
> + };
> + 

Re: [RFC 0/2] Do not stop with an error when mkimage fails

2021-11-11 Thread Heiko Thiery
Hi Wolfgang,

Am Do., 11. Nov. 2021 um 13:24 Uhr schrieb Wolfgang Denk :
>
> Dear Heiko,
>
> In message 
>  you 
> wrote:
> >
> > > Sorry, but this makes no sense to me.  If there is an error, it
> > > should be reported and - if possible - handled.  If this is not
> > > possible, then the correct thing is to abort.  Ignoring errors and
> > > trying to continue is always the worst thing to do.
> >
> > The only reason I want to introduce this is because I want to have my
> > imx8mq board built by CI. This board needs an external HDMI firmware
> > which is used by mkimage. But because this firmware is not available
> > in the CI build, it comes to the abort. With other boards it is also
> > so that in the CI external blobs are not available and these make
> > nevertheless without error a binman run. In this case only a warning
> > is output.
> >
> > I know this is not a perfect solution but I don't know how to get my
> > board merged without doing this kind of workaround for the U-Boot CI.
>
> It's not only not a perfect solution, it is the intentional
> introduction of a bug, and thus totally unacceptable.
>
> If there is a file missing in the CI, then add/create it there.
>
> But do remove necessary error handling which would cause hard to
> detec failures when for normal use.

I understand your attitude and am meanwhile also of this opinion. The
idea with the creation of dummy files I also had. I think we should go
in this direction. Everything else would probably be connected with
bigger changes.

-- 
Heiko


Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-11 Thread Michael Walle
> > If Linux driver does not need to be updated to support MPFS macb using
> > existing compatible string but U-Boot driver has to, something is
> > wrong on the U-Boot macb driver side.
> >
> > Would you please reconsider the whole changes?
> >
> We submitted patches(v1, v2) last year for the U-Boot MACB update for
> 64-bit DMA access same like Linux MACB driver using "#ifdef
> CONFIG_DMA_ADDR_T_64BIT" but one of the reviewer wanted to check 64-bit DMA
> support at runtime instead of #ifdef and we updated the macb driver based
> on the design config debug6 register of MACB hardware which supports 32-bit
> or 64-bit DMA in patch(v3) but the SiFive FU540 MACB didn't work then the
> reviewer suggested use compatible string instead of design config register
> and updated same in patch(v4), these changes were tested and acknowledged
> them at Patch v6.

I agree with Bin here. You shouldn't introduce a new compatible just for
u-boot. If you need one, please to it first in linux and get an ACK there.
Or at least there should be patches for it pending in linux and it should
be likely, that they will be accepted.

Please work towards having one binding for u-boot and linux.

-michael


Re: [RFC 0/2] Do not stop with an error when mkimage fails

2021-11-11 Thread Wolfgang Denk
Dear Rasmus,

In message <3253160d-b2e1-2101-5cd4-b8549b5ac...@prevas.dk> you wrote:
>
> > Yes, I believe the build system must be taught some env var (or other
> > means) for opting in to this behavior. 
>
> Oh, and it should of course only paper over missing binary blobs, not
> arbitrary errors from mkimage or other tools. The easiest way to do that
> is probably to create some dummy blob(s) [only when CREATE_BROKEN_IMAGES
> is set of course] before calling the tool that will consume the blobs.

Would it not make much more sense that the CI actually creates the
needed data, at least dummy versions of it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
:   I've tried (in vi) "g/[a-z]\n[a-z]/s//_/"...but that doesn't
: cut it.  Any ideas?  (I take it that it may be a two-pass sort of solution).
In the first pass, install perl. :-) Larry Wall <6...@jpl-devvax.jpl.nasa.gov>


Re: [RFC 0/2] Do not stop with an error when mkimage fails

2021-11-11 Thread Wolfgang Denk
Dear Tom,

In message <20211109194224.GB24579@bill-the-cat> you wrote:
> 
> > The only reason I want to introduce this is because I want to have my
> > imx8mq board built by CI. This board needs an external HDMI firmware
> > which is used by mkimage. But because this firmware is not available
> > in the CI build, it comes to the abort. With other boards it is also
> > so that in the CI external blobs are not available and these make
> > nevertheless without error a binman run. In this case only a warning
> > is output.
...
> Unfortunately in these days of needing multiple inputs to create a
> functional image and also needing to have CI be able to be at all
> useful, what we do in many many many cases is yell loudly to the user
> that the resulting file here will NOT work and why.  So yes, some "yell
> it won't work but not return non-zero exit status" is the norm.

This is a terrible degradtion from standard programming style, then.

> I would be very much open however to some way to handle this
> differently.  Some environment variable our tools check for and then
> yell-but-succeed?  Some other idea?  I'm just thinking out loud here.

Well, why not fix the root cause?

Heiko writes that "an external HDMI firmware" is needed - so the fix
is to provide one, or at least a dummy file which is good enough for
the build to succeed.  It should be trivial to create a dummy file
in the CI context, no?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"A little knowledge is a dangerous thing."- Doug Gwyn


Re: LMB and UEFI memory management not integrated.

2021-11-11 Thread Heinrich Schuchardt





__lmb_alloc_base() seems not be integrated with the UEFI sub-system. So UEFI
might hand out memory marked as reserved in the LMB sub-system.


Heinrich, do you plan to work on this?


I am not sure if I will have enough capacity to work on the LMB/UEFI 
integration. But it is surely an issue to be solved.


Best regards

Heinrich



It would be great if we could finally solve this situation with the
2022.01 release.

Right now Unmatched is probably the only board that doesn't turn off
the relocation, and thus some people hit the issues.

Looking at the git history, the LMB issue is fixed in v2022.01-rc1
only right now. Minus UEFI part, which is/will be important for
distributions.

david



I guess this is still a topic to be addressed.


If UEFI can still end up getting U-Boot overwritten, yes, that needs to
be addressed.  Only slightly surprised one of the capture-the-flag or
similar events hasn't come to us yet with some CVEs related to that,
too.

--
Tom


Re: [RFC 0/2] Do not stop with an error when mkimage fails

2021-11-11 Thread Wolfgang Denk
Dear Heiko,

In message  
you wrote:
>
> > Sorry, but this makes no sense to me.  If there is an error, it
> > should be reported and - if possible - handled.  If this is not
> > possible, then the correct thing is to abort.  Ignoring errors and
> > trying to continue is always the worst thing to do.
>
> The only reason I want to introduce this is because I want to have my
> imx8mq board built by CI. This board needs an external HDMI firmware
> which is used by mkimage. But because this firmware is not available
> in the CI build, it comes to the abort. With other boards it is also
> so that in the CI external blobs are not available and these make
> nevertheless without error a binman run. In this case only a warning
> is output.
>
> I know this is not a perfect solution but I don't know how to get my
> board merged without doing this kind of workaround for the U-Boot CI.

It's not only not a perfect solution, it is the intentional
introduction of a bug, and thus totally unacceptable.

If there is a file missing in the CI, then add/create it there.

But do remove necessary error handling which would cause hard to
detec failures when for normal use.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The moral of the story is: "Don't stop to  tighten  your  shoe  laces
during the Olympics 100m finals".
 - Kevin Jones in 


Re: [PATCH v2 2/2] board: mntre: imx8mq: Add MNT Reform 2 board support

2021-11-11 Thread Patrick Wildt
On Wed, Nov 10, 2021 at 02:26:54PM -0800, Vagrant Cascadian wrote:
> On 2021-09-02, Patrick Wildt wrote:
> > The MNT Reform 2 is a modular DIY laptop.  In its initial version it
> > is based on the BoundaryDevices i.MX8MQ SoM.  Some parts have been
> > lifted from BoundaryDevices official U-Boot downstream project.
> 
> Thanks for working on this!
> 
> I'm struggling a bit getting it to actually boot; how is this supposed
> to be installed to the device?
> 
> I've built with the two applied patches on a patched v2021.10, copying
> various firmware parts from:
> 
>   
> https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/bl31-iMX8MQ.bin
>   
> https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_1d_dmem.bin
>   
> https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_1d_imem.bin
>   
> https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_2d_dmem.bin
>   
> https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_2d_imem.bin
> 
>   export BL31=bl31-iMX8MQ.bin
> 
>   make imx8mq_reform2_defconfig
>   make
>   make flash.bin
> 
> Then grepping various other README's from imx8mq devices, I tried two
> different processes:
> 
>   dd if=flash.bin of=/dev/sd[x] bs=1K seek=33

You only need to dd flash.bin, the command looks fine.

> and:
> 
>   dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
>   dd if=u-boot.itb of=/dev/sd[x] bs=1024 seek=384 conv=sync
> 
> Both simply hanging with:
> 
>   U-Boot SPL 2021.10 (Jan 01 1970 - 00:00:01 +)

There have been a few changes in U-Boot since I sent my patchset, it's
possible the diff by itself might not be enough.

I will send out a new patchset soon, but the move to Binman doesn't work
for me yet.  It's weird, because I don't see a diff to other i.MX8MQ
platforms, so I'm still debugging that.  Maybe the other i.MX8MQ boards
don't work with Binman either?

Keep note that the build procedure (how to supply bl31) changes once
Binman is used.

> Is the flash.bin step unecessary? I see DDR timing code in the patch
> series; are corresponding lpddr4*.bin no longer necessary?

The flash.bin has all bits: U-Boot, U-Boot SPL, lpddr4*.bin and bl31.bin

lpddr4*.bin is the firmware for the DDR controller.  So you need the
timing information *and* the firmware.

> I also tried building with an old version of arm-trusted-firmware
> (v2.2), as that was the most recent upstream version that successfully
> built. This seems to be a fork of ATF that has support for iMX8MQ, but
> it is unclear which branch/tag/etc. should be used with the mnt/reform:
> 
>   https://source.codeaurora.org/external/imx/imx-atf

Not sure right now, but I think I was using the one that's build on
OpenBSD-current, which seems to be arm-trusted-firmware 2.5.  I'll
check it.

> It would be nice to include a board README in the next patch revision to
> spell out some of the details of exactly which other projects and
> versions/comments/branches are expected to work with MNT Reform2.
> 

This is nothing specific to the MNT Reform2.  It's the same for all
i.MX8MQ boards.  ATF+DDR+U-Boot have to work together, and it doesn't
matter which board it is.  Hence I don't believe providing that kind
information in a Reform-specific README makes sense.

Patrick

> 
> I would be nice if you could CC me on future patch series revisions to
> be able to test. Thanks!
> 
> 
> live well,
>   vagrant
> 
> 
> > Signed-off-by: Patrick Wildt 
> > ---
> >  arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi   |   11 +
> >  arch/arm/mach-imx/imx8m/Kconfig   |6 +
> >  board/mntre/imx8mq_reform2/Kconfig|   12 +
> >  board/mntre/imx8mq_reform2/MAINTAINERS|7 +
> >  board/mntre/imx8mq_reform2/Makefile   |   12 +
> >  board/mntre/imx8mq_reform2/imx8mq_reform2.c   |  213 
> >  board/mntre/imx8mq_reform2/lpddr4_timing.c| 1014 +
> >  .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h  |   95 ++
> >  board/mntre/imx8mq_reform2/spl.c  |  260 +
> >  configs/imx8mq_reform2_defconfig  |   67 ++
> >  include/configs/imx8mq_reform2.h  |  151 +++
> >  11 files changed, 1848 insertions(+)
> >  create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi
> >  create mode 100644 board/mntre/imx8mq_reform2/Kconfig
> >  create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS
> >  create mode 100644 board/mntre/imx8mq_reform2/Makefile
> >  create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c
> >  create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c
> >  create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h
> >  create mode 100644 board/mntre/imx8mq_reform2/spl.c
> >  create mode 100644 configs/imx8mq_reform2_defconfig
> >  create mode 100644 include/configs/imx8mq_reform2.h




[RFC PATCH v4 6/6] fpga: zynqmp: support loading authenticated images

2021-11-11 Thread Oleksandr Suvorov
Add supporting new compatible string "u-boot,zynqmp-fpga-ddrauth" to
handle loading authenticated images (DDR).

Based on solution by Jorge Ramirez-Ortiz 
Signed-off-by: Oleksandr Suvorov 
Co-developed-by: Ricardo Salveti 
Signed-off-by: Ricardo Salveti 
Tested-by: Ricardo Salveti 
---

Changes in v4:
- change interface to xilinx_desc->operations->open() callback.
- fix a bug from previous version of the patchset in dereferencing
  of a parent fpga_desc structure.

Changes in v3:
- remove the patch which introduced CMD_SPL_FPGA_LOAD_SECURE.
- fix mixing definitions/declarations.
- replace strcmp() calls with more secure strncmp().
- document the "u-boot,zynqmp-fpga-ddrauth" compatible string.
- fix code style by check-patch recommendations.

Changes in v2:
- add function fit_fpga_load() to simplify calls of fpga_load()
  from contexts without a compatible attribute.
- move all ZynqMP-specific logic to drivers/fpga/zynqmppl.c
- prepare for passing a "compatible" FDT property to any fpga driver.

 common/Kconfig.boot   |  4 ++--
 doc/uImage.FIT/source_file_format.txt |  5 -
 drivers/fpga/zynqmppl.c   | 21 +
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index a8d4be23a97..f8796541746 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -198,8 +198,8 @@ config SPL_LOAD_FIT
  1. "loadables" images, other than FDTs, which do not have a "load"
 property will not be loaded. This limitation also applies to FPGA
 images with the correct "compatible" string.
- 2. For FPGA images, only the "compatible" = "u-boot,fpga-legacy"
-loading method is supported.
+ 2. For FPGA images, the supported "compatible" list is in the
+doc/uImage.FIT/source_file_format.txt.
  3. FDTs are only loaded for images with an "os" property of "u-boot".
 "linux" images are also supported with Falcon boot mode.
 
diff --git a/doc/uImage.FIT/source_file_format.txt 
b/doc/uImage.FIT/source_file_format.txt
index f93ac6d1c7b..461e2af2a84 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -184,7 +184,10 @@ the '/images' node should have the following layout:
 Mandatory for types: "firmware", and "kernel".
   - compatible : compatible method for loading image.
 Mandatory for types: "fpga", and images that do not specify a load address.
-To use the generic fpga loading routine, use "u-boot,fpga-legacy".
+Supported compatible methods:
+"u-boot,fpga-legacy" - the generic fpga loading routine.
+"u-boot,zynqmp-fpga-ddrauth" - signed non-encrypted FPGA bitstream for
+Xilinx Zynq UltraScale+ (ZymqMP) device.
 
   Optional nodes:
   - hash-1 : Each hash sub-node represents separate hash or checksum
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index c7f9f4ae846..59948afa3ee 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -210,6 +211,26 @@ static int zynqmp_load(xilinx_desc **desc_ptr, const void 
*buf, size_t bsize,
u32 ret_payload[PAYLOAD_ARG_CNT];
bool xilfpga_old = false;
xilinx_desc *desc = *desc_ptr;
+   fpga_desc *fdesc = container_of((void *)desc_ptr, fpga_desc, devdesc);
+
+   if (fdesc && fdesc->compatible &&
+   !strcmp(fdesc->compatible, "u-boot,zynqmp-fpga-ddrauth")) {
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
+   struct fpga_secure_info info = { 0 };
+
+   if (!desc->operations->loads) {
+   printf("%s: Missing load operation\n", __func__);
+   return FPGA_FAIL;
+   }
+   /* DDR authentication */
+   info.authflag = 1;
+   info.encflag = 2;
+   return desc->operations->loads(desc, buf, bsize, &info);
+#else
+   printf("No support for %s\n", fdesc->compatible);
+   return FPGA_FAIL;
+#endif
+   }
 
if (zynqmp_firmware_version() <= PMUFW_V1_0) {
puts("WARN: PMUFW v1.0 or less is detected\n");
-- 
2.31.1



[RFC PATCH v4 2/6] fpga: add fit_fpga_load function

2021-11-11 Thread Oleksandr Suvorov
Introduce a function which passes an fpga compatible string from
FIT images to FPGA drivers. This lets the different implementations
decide how to handle it.

Some code of Jorge Ramirez-Ortiz  is reused.

Signed-off-by: Oleksandr Suvorov 
Tested-by: Ricardo Salveti 
---

(no changes since v1)

 common/spl/spl_fit.c |  6 ++
 drivers/fpga/fpga.c  | 35 ---
 include/fpga.h   |  4 
 3 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 5fe0273d66d..bd29e8c59d4 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -580,11 +580,9 @@ static int spl_fit_upload_fpga(struct spl_fit_info *ctx, 
int node,
compatible = fdt_getprop(ctx->fit, node, "compatible", NULL);
if (!compatible)
warn_deprecated("'fpga' image without 'compatible' property");
-   else if (strcmp(compatible, "u-boot,fpga-legacy"))
-   printf("Ignoring compatible = %s property\n", compatible);
 
-   ret = fpga_load(0, (void *)fpga_image->load_addr, fpga_image->size,
-   BIT_FULL);
+   ret = fit_fpga_load(0, (void *)fpga_image->load_addr, fpga_image->size,
+   BIT_FULL, compatible);
if (ret) {
printf("%s: Cannot load the image to the FPGA\n", __func__);
return ret;
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 3b0a44b2420..2266c7d83a4 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -197,9 +197,9 @@ int fpga_fsload(int devnum, const void *buf, size_t size,
 fpga_fs_info *fpga_fsinfo)
 {
int ret_val = FPGA_FAIL;   /* assume failure */
-   const fpga_desc *desc = fpga_validate(devnum, buf, size,
- (char *)__func__);
+   const fpga_desc *desc;
 
+   desc = fpga_validate(devnum, buf, size, (char *)__func__);
if (desc) {
switch (desc->devtype) {
case fpga_xilinx:
@@ -225,10 +225,9 @@ int fpga_loads(int devnum, const void *buf, size_t size,
   struct fpga_secure_info *fpga_sec_info)
 {
int ret_val = FPGA_FAIL;
+   const fpga_desc *desc;
 
-   const fpga_desc *desc = fpga_validate(devnum, buf, size,
- (char *)__func__);
-
+   desc = fpga_validate(devnum, buf, size, (char *)__func__);
if (desc) {
switch (desc->devtype) {
case fpga_xilinx:
@@ -249,15 +248,31 @@ int fpga_loads(int devnum, const void *buf, size_t size,
 }
 #endif
 
+int fit_fpga_load(int devnum, const void *buf, size_t bsize,
+ bitstream_type bstype, const char *compatible)
+{
+   fpga_desc *desc = (fpga_desc *)fpga_validate(devnum, buf, bsize,
+ (char *)__func__);
+
+   if (!desc)
+   return FPGA_FAIL;
+   /*
+* Store the compatible string to proceed it in underlying
+* functions
+*/
+   desc->compatible = (char *)compatible;
+
+   return fpga_load(devnum, buf, bsize, bstype);
+}
 /*
- * Generic multiplexing code
+ * Generic multiplexing code:
+ * Each architecture must handle the mandatory FPGA DT compatible property.
  */
 int fpga_load(int devnum, const void *buf, size_t bsize, bitstream_type bstype)
 {
int ret_val = FPGA_FAIL;   /* assume failure */
const fpga_desc *desc = fpga_validate(devnum, buf, bsize,
  (char *)__func__);
-
if (desc) {
switch (desc->devtype) {
case fpga_xilinx:
@@ -270,6 +285,9 @@ int fpga_load(int devnum, const void *buf, size_t bsize, 
bitstream_type bstype)
break;
case fpga_altera:
 #if defined(CONFIG_FPGA_ALTERA)
+   if (strncmp(desc->compatible, "u-boot,fpga-legacy", 18))
+   printf("Ignoring compatible = %s property\n",
+  desc->compatible);
ret_val = altera_load(desc->devdesc, buf, bsize);
 #else
fpga_no_sup((char *)__func__, "Altera devices");
@@ -277,6 +295,9 @@ int fpga_load(int devnum, const void *buf, size_t bsize, 
bitstream_type bstype)
break;
case fpga_lattice:
 #if defined(CONFIG_FPGA_LATTICE)
+   if (strncmp(desc->compatible, "u-boot,fpga-legacy", 18))
+   printf("Ignoring compatible = %s property\n",
+  desc->compatible);
ret_val = lattice_load(desc->devdesc, buf, bsize);
 #else
fpga_no_sup((char *)__func__, "Lattice devices");
diff --git a/include/fpga.h b/include/fpga.h
index ec5144334df..2891f321061 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -35,6 +35,7 @@ typedef enu

[RFC PATCH v4 5/6] fpga: xilinx: pass xilinx_desc pointer address into load() ops

2021-11-11 Thread Oleksandr Suvorov
Pass an address of xilinx_desc pointer in an fpga_desc into a load()
callback of struct xilinx_fpga_op.
It allows getting parent fpga_desc structure members inside xilinx
fpga drivers.

Signed-off-by: Oleksandr Suvorov 
Tested-by: Ricardo Salveti 
---

(no changes since v1)

 drivers/fpga/spartan2.c | 3 ++-
 drivers/fpga/spartan3.c | 3 ++-
 drivers/fpga/versalpl.c | 2 +-
 drivers/fpga/virtex2.c  | 3 ++-
 drivers/fpga/xilinx.c   | 2 +-
 drivers/fpga/zynqmppl.c | 5 +++--
 drivers/fpga/zynqpl.c   | 3 ++-
 include/xilinx.h| 2 +-
 8 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/fpga/spartan2.c b/drivers/fpga/spartan2.c
index 3435400e58b..f40edb1747b 100644
--- a/drivers/fpga/spartan2.c
+++ b/drivers/fpga/spartan2.c
@@ -40,10 +40,11 @@ static int spartan2_ss_dump(xilinx_desc *desc, const void 
*buf, size_t bsize);
 
 /* - */
 /* Spartan-II Generic Implementation */
-static int spartan2_load(xilinx_desc *desc, const void *buf, size_t bsize,
+static int spartan2_load(xilinx_desc **desc_ptr, const void *buf, size_t bsize,
 bitstream_type bstype)
 {
int ret_val = FPGA_FAIL;
+   xilinx_desc *desc = *desc_ptr;
 
switch (desc->iface) {
case slave_serial:
diff --git a/drivers/fpga/spartan3.c b/drivers/fpga/spartan3.c
index 4850c99352d..b7c1ddd40f6 100644
--- a/drivers/fpga/spartan3.c
+++ b/drivers/fpga/spartan3.c
@@ -44,10 +44,11 @@ static int spartan3_ss_dump(xilinx_desc *desc, const void 
*buf, size_t bsize);
 
 /* - */
 /* Spartan-II Generic Implementation */
-static int spartan3_load(xilinx_desc *desc, const void *buf, size_t bsize,
+static int spartan3_load(xilinx_desc **desc_ptr, const void *buf, size_t bsize,
 bitstream_type bstype)
 {
int ret_val = FPGA_FAIL;
+   xilinx_desc *desc = *desc_ptr;
 
switch (desc->iface) {
case slave_serial:
diff --git a/drivers/fpga/versalpl.c b/drivers/fpga/versalpl.c
index c44a7d34557..9464cae22ee 100644
--- a/drivers/fpga/versalpl.c
+++ b/drivers/fpga/versalpl.c
@@ -26,7 +26,7 @@ static ulong versal_align_dma_buffer(ulong *buf, u32 len)
return (ulong)buf;
 }
 
-static int versal_load(xilinx_desc *desc, const void *buf, size_t bsize,
+static int versal_load(xilinx_desc **desc_ptr, const void *buf, size_t bsize,
   bitstream_type bstype)
 {
ulong bin_buf;
diff --git a/drivers/fpga/virtex2.c b/drivers/fpga/virtex2.c
index b3e0537bab0..d0369d320b1 100644
--- a/drivers/fpga/virtex2.c
+++ b/drivers/fpga/virtex2.c
@@ -93,10 +93,11 @@ static int virtex2_ssm_dump(xilinx_desc *desc, const void 
*buf, size_t bsize);
 static int virtex2_ss_load(xilinx_desc *desc, const void *buf, size_t bsize);
 static int virtex2_ss_dump(xilinx_desc *desc, const void *buf, size_t bsize);
 
-static int virtex2_load(xilinx_desc *desc, const void *buf, size_t bsize,
+static int virtex2_load(xilinx_desc **desc_ptr, const void *buf, size_t bsize,
bitstream_type bstype)
 {
int ret_val = FPGA_FAIL;
+   xilinx_desc *desc = *desc_ptr;
 
switch (desc->iface) {
case slave_serial:
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index 640baac66e6..f89ae8fe103 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -153,7 +153,7 @@ int xilinx_load(xilinx_desc **desc_ptr, const void *buf, 
size_t bsize,
return FPGA_FAIL;
}
 
-   return desc->operations->load(desc, buf, bsize, bstype);
+   return desc->operations->load(desc_ptr, buf, bsize, bstype);
 }
 
 #if defined(CONFIG_CMD_FPGA_LOADFS)
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index 8ff12bf50a0..c7f9f4ae846 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -199,8 +199,8 @@ static int zynqmp_validate_bitstream(xilinx_desc *desc, 
const void *buf,
return 0;
 }
 
-static int zynqmp_load(xilinx_desc *desc, const void *buf, size_t bsize,
-bitstream_type bstype)
+static int zynqmp_load(xilinx_desc **desc_ptr, const void *buf, size_t bsize,
+  bitstream_type bstype)
 {
ALLOC_CACHE_ALIGN_BUFFER(u32, bsizeptr, 1);
u32 swap = 0;
@@ -209,6 +209,7 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf, 
size_t bsize,
u32 buf_lo, buf_hi;
u32 ret_payload[PAYLOAD_ARG_CNT];
bool xilfpga_old = false;
+   xilinx_desc *desc = *desc_ptr;
 
if (zynqmp_firmware_version() <= PMUFW_V1_0) {
puts("WARN: PMUFW v1.0 or less is detected\n");
diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index 2de40109a81..c5d9dbcedfd 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -370,11 +370,12 @@ static int zynq_validate_bitstream(xilinx_desc *desc, 
const void *buf,
return 0;
 }
 
-static int zynq_

[RFC PATCH v4 1/6] fpga: add option for loading FPGA secure bitstreams

2021-11-11 Thread Oleksandr Suvorov
It allows using this feature without enabling the "fpga loads"
command.

Signed-off-by: Oleksandr Suvorov 
Tested-by: Ricardo Salveti 
---

(no changes since v1)

 cmd/Kconfig |  3 ++-
 drivers/fpga/Kconfig| 14 ++
 drivers/fpga/fpga.c |  2 +-
 drivers/fpga/xilinx.c   |  2 +-
 drivers/fpga/zynqmppl.c |  4 ++--
 5 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e438..270d1765d35 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -949,8 +949,9 @@ config CMD_FPGA_LOADP
  a partial bitstream.
 
 config CMD_FPGA_LOAD_SECURE
-   bool "fpga loads - loads secure bitstreams (Xilinx only)"
+   bool "fpga loads - loads secure bitstreams"
depends on CMD_FPGA
+   select FPGA_LOAD_SECURE
help
  Enables the fpga loads command which is used to load secure
  (authenticated or encrypted or both) bitstreams on to FPGA.
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index dc0b3dd31b7..262f95a252a 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -85,4 +85,18 @@ config FPGA_ZYNQPL
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Xilinx Zynq devices.
 
+config FPGA_LOAD_SECURE
+   bool "Enable loading secure bitstreams"
+   depends on FPGA
+   help
+ Enables the fpga loads() functions that are used to load secure
+ (authenticated or encrypted or both) bitstreams on to FPGA.
+
+config SPL_FPGA_LOAD_SECURE
+   bool "Enable loading secure bitstreams for SPL"
+   depends on FPGA
+   help
+ Enables the fpga loads() functions that are used to load secure
+ (authenticated or encrypted or both) bitstreams on to FPGA.
+
 endmenu
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index fe3dfa12335..3b0a44b2420 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -220,7 +220,7 @@ int fpga_fsload(int devnum, const void *buf, size_t size,
 }
 #endif
 
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
 int fpga_loads(int devnum, const void *buf, size_t size,
   struct fpga_secure_info *fpga_sec_info)
 {
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index cbebefb55fe..6bc1bc491fb 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -172,7 +172,7 @@ int xilinx_loadfs(xilinx_desc *desc, const void *buf, 
size_t bsize,
 }
 #endif
 
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
 int xilinx_loads(xilinx_desc *desc, const void *buf, size_t bsize,
 struct fpga_secure_info *fpga_sec_info)
 {
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index 6b394869dbf..8ff12bf50a0 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -245,7 +245,7 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf, 
size_t bsize,
return ret;
 }
 
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE) && !defined(CONFIG_SPL_BUILD)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
 static int zynqmp_loads(xilinx_desc *desc, const void *buf, size_t bsize,
struct fpga_secure_info *fpga_sec_info)
 {
@@ -306,7 +306,7 @@ static int zynqmp_pcap_info(xilinx_desc *desc)
 
 struct xilinx_fpga_op zynqmp_op = {
.load = zynqmp_load,
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE) && !defined(CONFIG_SPL_BUILD)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
.loads = zynqmp_loads,
 #endif
.info = zynqmp_pcap_info,
-- 
2.31.1



[RFC PATCH v4 3/6] fpga: xilinx: pass an address of xilinx_desc in fpga_desc

2021-11-11 Thread Oleksandr Suvorov
Pass an address of xilinx_desc pointer in an fpga_desc  to use parent
fpga_desc structure members inside a xilinx fpga driver.

Signed-off-by: Oleksandr Suvorov 
Tested-by: Ricardo Salveti 
---

(no changes since v1)

 drivers/fpga/fpga.c   | 4 ++--
 drivers/fpga/xilinx.c | 4 +++-
 include/xilinx.h  | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 2266c7d83a4..781ab8bbef0 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -277,8 +277,8 @@ int fpga_load(int devnum, const void *buf, size_t bsize, 
bitstream_type bstype)
switch (desc->devtype) {
case fpga_xilinx:
 #if defined(CONFIG_FPGA_XILINX)
-   ret_val = xilinx_load(desc->devdesc, buf, bsize,
- bstype);
+   ret_val = xilinx_load((xilinx_desc **)&desc->devdesc,
+ buf, bsize, bstype);
 #else
fpga_no_sup((char *)__func__, "Xilinx devices");
 #endif
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index 6bc1bc491fb..640baac66e6 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -138,9 +138,11 @@ int fpga_loadbitstream(int devnum, char *fpgadata, size_t 
size,
return fpga_load(devnum, dataptr, swapsize, bstype);
 }
 
-int xilinx_load(xilinx_desc *desc, const void *buf, size_t bsize,
+int xilinx_load(xilinx_desc **desc_ptr, const void *buf, size_t bsize,
bitstream_type bstype)
 {
+   xilinx_desc *desc = *desc_ptr;
+
if (!xilinx_validate (desc, (char *)__FUNCTION__)) {
printf ("%s: Invalid device descriptor\n", __FUNCTION__);
return FPGA_FAIL;
diff --git a/include/xilinx.h b/include/xilinx.h
index ab4537becfa..57b0e7be113 100644
--- a/include/xilinx.h
+++ b/include/xilinx.h
@@ -58,7 +58,7 @@ struct xilinx_fpga_op {
 
 /* Generic Xilinx Functions
  */
-int xilinx_load(xilinx_desc *desc, const void *image, size_t size,
+int xilinx_load(xilinx_desc **desc_ptr, const void *image, size_t size,
bitstream_type bstype);
 int xilinx_dump(xilinx_desc *desc, const void *buf, size_t bsize);
 int xilinx_info(xilinx_desc *desc);
-- 
2.31.1



[RFC PATCH v4 4/6] fpga: xilinx: add missed identifier names

2021-11-11 Thread Oleksandr Suvorov
Function definition arguments should also have identifier names.
Add missed ones to struct xilinx_fpga_op callbacks, unifying code.

Signed-off-by: Oleksandr Suvorov 
---

(no changes since v1)

 include/xilinx.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/xilinx.h b/include/xilinx.h
index 57b0e7be113..06ecc9a842c 100644
--- a/include/xilinx.h
+++ b/include/xilinx.h
@@ -48,12 +48,14 @@ typedef struct {/* typedef xilinx_desc */
 } xilinx_desc; /* end, typedef xilinx_desc */
 
 struct xilinx_fpga_op {
-   int (*load)(xilinx_desc *, const void *, size_t, bitstream_type);
-   int (*loadfs)(xilinx_desc *, const void *, size_t, fpga_fs_info *);
+   int (*load)(xilinx_desc *desc, const void *buf, size_t bsize,
+   bitstream_type bstype);
+   int (*loadfs)(xilinx_desc *desc, const void *buf, size_t bsize,
+ fpga_fs_info *fpga_fsinfo);
int (*loads)(xilinx_desc *desc, const void *buf, size_t bsize,
 struct fpga_secure_info *fpga_sec_info);
-   int (*dump)(xilinx_desc *, const void *, size_t);
-   int (*info)(xilinx_desc *);
+   int (*dump)(xilinx_desc *desc, const void *buf, size_t bsize);
+   int (*info)(xilinx_desc *desc);
 };
 
 /* Generic Xilinx Functions
-- 
2.31.1



[RFC PATCH v4 0/6] fpga: zynqmp: Adding support of loading authenticated images

2021-11-11 Thread Oleksandr Suvorov


Note: this version of the patchset changes the interface to the
load() callback of xilinx_fpga_op.

This patchset introduces support for the authenticated FPGA images
on ZynqMP boards, besides that introducing common way to pass the
compatible property to any fpga driver.

It bases on the initial work by Jorge Ramirez-Ortiz 
https://patchwork.ozlabs.org/project/uboot/patch/20211015091506.2602-1-jo...@foundries.io/
https://patchwork.ozlabs.org/project/uboot/patch/20211005111324.19749-3-jo...@foundries.io/

Changes in v4:
- change interface to xilinx_desc->operations->load() callback.
- fix a bug from previous version of the patchset in dereferencing
  of a parent fpga_desc structure.

Changes in v3:
- remove the patch which introduced CMD_SPL_FPGA_LOAD_SECURE.
- fix mixing definitions/declarations.
- replace strcmp() calls with more secure strncmp().
- document the "u-boot,zynqmp-fpga-ddrauth" compatible string.
- fix code style by check-patch recommendations.

Changes in v2:
- add function fit_fpga_load() to simplify calls of fpga_load()
  from contexts without a compatible attribute.
- move all ZynqMP-specific logic to drivers/fpga/zynqmppl.c
- prepare for passing a "compatible" FDT property to any fpga driver.

Oleksandr Suvorov (6):
  fpga: add option for loading FPGA secure bitstreams
  fpga: add fit_fpga_load function
  fpga: xilinx: pass an address of xilinx_desc in fpga_desc
  fpga: xilinx: add missed identifier names
  fpga: xilinx: pass xilinx_desc pointer address into load() ops
  fpga: zynqmp: support loading authenticated images

 cmd/Kconfig   |  3 +-
 common/Kconfig.boot   |  4 +--
 common/spl/spl_fit.c  |  6 ++--
 doc/uImage.FIT/source_file_format.txt |  5 +++-
 drivers/fpga/Kconfig  | 14 +
 drivers/fpga/fpga.c   | 41 ---
 drivers/fpga/spartan2.c   |  3 +-
 drivers/fpga/spartan3.c   |  3 +-
 drivers/fpga/versalpl.c   |  2 +-
 drivers/fpga/virtex2.c|  3 +-
 drivers/fpga/xilinx.c |  8 --
 drivers/fpga/zynqmppl.c   | 30 +---
 drivers/fpga/zynqpl.c |  3 +-
 include/fpga.h|  4 +++
 include/xilinx.h  | 12 
 15 files changed, 106 insertions(+), 35 deletions(-)

-- 
2.31.1



Re: [PATCH v2 1/2] board: sifive: unmatched: use zero copy for initrd

2021-11-11 Thread David Abdurachmanov
On Tue, Nov 9, 2021 at 7:11 PM Tom Rini  wrote:
>
> On Tue, Nov 09, 2021 at 05:27:52PM +0100, Heinrich Schuchardt wrote:
> > On 11/9/21 17:07, Tom Rini wrote:
> > > On Tue, Nov 09, 2021 at 04:50:27PM +0100, Heinrich Schuchardt wrote:
> > > > On 11/9/21 16:46, Tom Rini wrote:
> > > > > On Tue, Nov 09, 2021 at 03:46:00PM +0100, Heinrich Schuchardt wrote:
> > > > >
> > > > > > Booting Ubuntu Impish showed the following output:
> > > > > >
> > > > > >   relocaddr   = 0xfff6
> > > > > >
> > > > > >   Loading Ramdisk to fa118000, end f19d ...
> > > > > >
> > > > > > The initrd is overwriting the U-Boot binary. Booting fails.
> > > > > >
> > > > > > There is no need to copy the initrd from $ramdisk_addr_r.
> > > > > > Set init_high = ~0UL to use zero copy. Do the same for the device 
> > > > > > tree.
> > > > > >
> > > > > > Same for the devicetree.
> > > > > >
> > > > > > Signed-off-by: Heinrich Schuchardt 
> > > > > > 
> > > > > > ---
> > > > > > v2:
> > > > > >   Don't copy fdt either.
> > > > > > ---
> > > > > >include/configs/sifive-unmatched.h | 2 ++
> > > > > >1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/include/configs/sifive-unmatched.h 
> > > > > > b/include/configs/sifive-unmatched.h
> > > > > > index f68d7d7676..69a4eb2f2a 100644
> > > > > > --- a/include/configs/sifive-unmatched.h
> > > > > > +++ b/include/configs/sifive-unmatched.h
> > > > > > @@ -59,6 +59,8 @@
> > > > > >   "name=system,size=-,bootable,type=${type_guid_gpt_system};"
> > > > > >#define CONFIG_EXTRA_ENV_SETTINGS \
> > > > > > + "fdt_high=0x\0" \
> > > > > > + "initrd_high=0x\0" \
> > > > > >   "kernel_addr_r=0x8400\0" \
> > > > > >   "fdt_addr_r=0x8800\0" \
> > > > > >   "scriptaddr=0x8810\0" \
> > > > >
> > > > > I know I'm doing this out of order, but I'm going to repeat myself 
> > > > > here
> > > > > too.  You cannot disable device tree relocation.  I cannot count the
> > > > > number of hours that have been wasted because of this mis-feature due 
> > > > > to
> > > > > misalignment of the device tree or overwriting of the device tree and
> > > > > then U-Boot not fixing it because it was told not to, and then people
> > > > > and projects wasting countless hours over it.  It's why checkpatch.pl
> > > > > throws out an ERROR on this now.  I didn't yell even more loudly
> > > > > previously at riscv because as it was missing the arch_lmb portion to
> > > > > avoid overwriting U-Boot at run-time, it still was a problem.  But
> > > > > that's been fixed.  So, no.  NAK.
> > > >
> > > > Why should the devicetree relocated?
> > > > This should never have been enabled on RISC-V.
> > >
> > > To repeat myself, because RISC-V has been broken until very recently and
> > > lacked the parts of lmb to avoid overwriting U-Boot while running, is
> > > why any platforms have been allowed in with fdt/initrd_high set to
> > > disable relocation.  As that problem has now been fixed, fdt relocation
> > > must be re-enabled on the currently wrong platforms, and will not be
> > > allowed on new platforms.
> > >
> > > There are specific deployment cases where the developer can choose to
> > > disable relocation because they know that there will never be a way for
> > > things to be done in an overlapping manner because the system is locked
> > > down.  That is very rarely the case for mainline and absolutely not the
> > > case for a general purpose board like the unmatched.
> >
> > __lmb_alloc_base() seems not be integrated with the UEFI sub-system. So UEFI
> > might hand out memory marked as reserved in the LMB sub-system.

Heinrich, do you plan to work on this?

It would be great if we could finally solve this situation with the
2022.01 release.

Right now Unmatched is probably the only board that doesn't turn off
the relocation, and thus some people hit the issues.

Looking at the git history, the LMB issue is fixed in v2022.01-rc1
only right now. Minus UEFI part, which is/will be important for
distributions.

david

> >
> > I guess this is still a topic to be addressed.
>
> If UEFI can still end up getting U-Boot overwritten, yes, that needs to
> be addressed.  Only slightly surprised one of the capture-the-flag or
> similar events hasn't come to us yet with some CVEs related to that,
> too.
>
> --
> Tom


macb clock handling (Was: [PATCH v1 4/5] net: macb: Compatible as per device tree)

2021-11-11 Thread Heiko Stübner
Hi,

not wanting to hijack this too much, but does the mac driver also need
some sort of clock handling?

Because on the Icicle I have here, I'm running into "TX timeout" errors:

RISC-V # dhcp
ethernet@20112000: PHY present at 9
ethernet@20112000: Starting autonegotiation...
ethernet@20112000: Autonegotiation complete
ethernet@20112000: link up, 1000Mbps full-duplex (lpa: 0x3800)
BOOTP broadcast 1
ethernet@20112000: TX timeout
BOOTP broadcast 2
ethernet@20112000: TX timeout
BOOTP broadcast 3
ethernet@20112000: TX timeout
BOOTP broadcast 4
ethernet@20112000: TX timeout

The sifive variant of the macb distinguishes between speeds in its
cllk_init callback, so I guess the Icicle might need that as well?


Thanks
Heiko

Am Freitag, 22. Oktober 2021, 10:56:47 CET schrieb Padmarao Begari:
> Update compatible as per Microchip PolarFire SoC ethernet
> device node.
> 
> Signed-off-by: Padmarao Begari 
> ---
>  drivers/net/macb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 8c6461e717..1b867bd5c2 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -1502,7 +1502,7 @@ static const struct udevice_id macb_eth_ids[] = {
>   { .compatible = "cdns,zynq-gem" },
>   { .compatible = "sifive,fu540-c000-gem",
> .data = (ulong)&sifive_config },
> - { .compatible = "microchip,mpfs-mss-gem",
> + { .compatible = "microchip,mpfs-gem",
> .data = (ulong)µchip_config },
>   { }
>  };
> 






[PATCH v2 5/5] vexpress64: Enable VIRTIO_NET network driver

2021-11-11 Thread Peter Hoyes
From: Peter Hoyes 

The SMSC driver is using the old driver model.

Init the virtio system in vexpress64.c so that the network device is
discovered.

Signed-off-by: Peter Hoyes 
---
 board/armltd/vexpress64/vexpress64.c | 7 +++
 include/configs/vexpress_aemv8.h | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/board/armltd/vexpress64/vexpress64.c 
b/board/armltd/vexpress64/vexpress64.c
index d17b463be5..5e22e89824 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -18,6 +18,10 @@
 #include 
 #include "pcie.h"
 #include 
+#ifdef CONFIG_VIRTIO_NET
+#include 
+#include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -64,6 +68,9 @@ __weak void vexpress64_pcie_init(void)
 int board_init(void)
 {
vexpress64_pcie_init();
+#ifdef CONFIG_VIRTIO_NET
+   virtio_init();
+#endif
return 0;
 }
 
diff --git a/include/configs/vexpress_aemv8.h b/include/configs/vexpress_aemv8.h
index 7cdfc30649..faa7065086 100644
--- a/include/configs/vexpress_aemv8.h
+++ b/include/configs/vexpress_aemv8.h
@@ -88,8 +88,8 @@
 #endif
 #endif /* !CONFIG_GICV3 */
 
-#ifndef CONFIG_TARGET_VEXPRESS64_JUNO
-/* The Vexpress64 simulators use SMSC91C111 */
+#if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) && !defined(CONFIG_DM_ETH)
+/* The Vexpress64 BASE_FVP simulator uses SMSC91C111 */
 #define CONFIG_SMC91
 #define CONFIG_SMC9_BASE   (V2M_PA_BASE + 0x01A00)
 #endif
-- 
2.25.1



[PATCH v2 4/5] vexpress64: Enable OF_CONTROL and OF_BOARD for VExpress64

2021-11-11 Thread Peter Hoyes
From: Peter Hoyes 

Capture x0 in lowlevel_init.S as potential fdt address. Modify
board_fdt_blob_setup to use fdt address from either vexpress_aemv8.h
or lowlevel_init.S.

Signed-off-by: Peter Hoyes 
---
 board/armltd/vexpress64/Makefile|  2 +-
 board/armltd/vexpress64/lowlevel_init.S | 12 
 board/armltd/vexpress64/vexpress64.c| 26 +
 3 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 board/armltd/vexpress64/lowlevel_init.S

diff --git a/board/armltd/vexpress64/Makefile b/board/armltd/vexpress64/Makefile
index 868dc4f629..1878fbed4e 100644
--- a/board/armltd/vexpress64/Makefile
+++ b/board/armltd/vexpress64/Makefile
@@ -3,5 +3,5 @@
 # (C) Copyright 2000-2004
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 
-obj-y  := vexpress64.o
+obj-y  := vexpress64.o lowlevel_init.o
 obj-$(CONFIG_TARGET_VEXPRESS64_JUNO)   += pcie.o
diff --git a/board/armltd/vexpress64/lowlevel_init.S 
b/board/armltd/vexpress64/lowlevel_init.S
new file mode 100644
index 00..3dcfb85d0e
--- /dev/null
+++ b/board/armltd/vexpress64/lowlevel_init.S
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * (C) Copyright 2021 Arm Limited
+ */
+
+.global save_boot_params
+save_boot_params:
+
+   adr x8, prior_stage_fdt_address
+   str x0, [x8]
+
+   b   save_boot_params_ret
diff --git a/board/armltd/vexpress64/vexpress64.c 
b/board/armltd/vexpress64/vexpress64.c
index d2f307cca5..d17b463be5 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -85,7 +85,15 @@ int dram_init_banksize(void)
return 0;
 }
 
+/* Assigned in lowlevel_init.S
+ * Push the variable into the .data section so that it
+ * does not get cleared later.
+ */
+unsigned long __section(".data") prior_stage_fdt_address;
+
 #ifdef CONFIG_OF_BOARD
+
+#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
 #define JUNO_FLASH_SEC_SIZE(256 * 1024)
 static phys_addr_t find_dtb_in_nor_flash(const char *partname)
 {
@@ -130,9 +138,11 @@ static phys_addr_t find_dtb_in_nor_flash(const char 
*partname)
 
return ~0;
 }
+#endif
 
 void *board_fdt_blob_setup(int *err)
 {
+#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
phys_addr_t fdt_rom_addr = find_dtb_in_nor_flash(CONFIG_JUNO_DTB_PART);
 
*err = 0;
@@ -142,6 +152,22 @@ void *board_fdt_blob_setup(int *err)
}
 
return (void *)fdt_rom_addr;
+#endif
+
+#ifdef VEXPRESS_FDT_ADDR
+   if (fdt_magic(VEXPRESS_FDT_ADDR) == FDT_MAGIC) {
+   *err = 0;
+   return (void *)VEXPRESS_FDT_ADDR;
+   }
+#endif
+
+   if (fdt_magic(prior_stage_fdt_address) == FDT_MAGIC) {
+   *err = 0;
+   return (void *)prior_stage_fdt_address;
+   }
+
+   *err = -ENXIO;
+   return NULL;
 }
 #endif
 
-- 
2.25.1



[PATCH v2 3/5] vexpress64: Clean up BASE_FVP boot configuration

2021-11-11 Thread Peter Hoyes
From: Peter Hoyes 

Move env var address values to #defines so they can be reused elsewhere.

Rename env var names to those recommended in the README and modify
addresses to allow more space for the kernel.

Fix issue where fdt is called with invalid arguments when booting
without a ramdisk.

Signed-off-by: Peter Hoyes 
---
 include/configs/vexpress_aemv8.h | 50 
 1 file changed, 31 insertions(+), 19 deletions(-)

diff --git a/include/configs/vexpress_aemv8.h b/include/configs/vexpress_aemv8.h
index 49517a60b0..7cdfc30649 100644
--- a/include/configs/vexpress_aemv8.h
+++ b/include/configs/vexpress_aemv8.h
@@ -7,6 +7,8 @@
 #ifndef __VEXPRESS_AEMV8_H
 #define __VEXPRESS_AEMV8_H
 
+#include 
+
 #define CONFIG_REMAKE_ELF
 
 /* Link Definitions */
@@ -172,33 +174,43 @@
BOOTENV
 
 #elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
+
+#define VEXPRESS_KERNEL_ADDR   0x8008
+#define VEXPRESS_FDT_ADDR  0x8fc0
+#define VEXPRESS_BOOT_ADDR 0x8fd0
+#define VEXPRESS_RAMDISK_ADDR  0x8fe0
+
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"kernel_name=Image\0"   \
-   "kernel_addr=0x8008\0"  \
-   "initrd_name=ramdisk.img\0" \
-   "initrd_addr=0x8800\0"  \
-   "fdtfile=devtree.dtb\0" \
-   "fdt_addr=0x8300\0" \
-   "boot_name=boot.img\0"  \
-   "boot_addr=0x8007f800\0"
+   "kernel_addr_r=" 
__stringify(VEXPRESS_KERNEL_ADDR) "\0" \
+   "ramdisk_name=ramdisk.img\0"\
+   "ramdisk_addr_r=" 
__stringify(VEXPRESS_RAMDISK_ADDR) "\0" \
+   "fdtfile=devtree.dtb\0" \
+   "fdt_addr_r=" __stringify(VEXPRESS_FDT_ADDR) 
"\0"   \
+   "boot_name=boot.img\0" \
+   "boot_addr_r=" __stringify(VEXPRESS_BOOT_ADDR) 
"\0"
 
 #ifndef CONFIG_BOOTCOMMAND
-#define CONFIG_BOOTCOMMAND "if smhload ${boot_name} ${boot_addr}; then " \
+#define CONFIG_BOOTCOMMAND "if smhload ${boot_name} ${boot_addr_r}; then " 
\
"  set bootargs; " \
-   "  abootimg addr ${boot_addr}; " \
-   "  abootimg get dtb --index=0 fdt_addr; " \
-   "  bootm ${boot_addr} ${boot_addr} " \
-   "  ${fdt_addr}; " \
+   "  abootimg addr ${boot_addr_r}; " \
+   "  abootimg get dtb --index=0 fdt_addr_r; " \
+   "  bootm ${boot_addr_r} ${boot_addr_r} " \
+   "  ${fdt_addr_r}; " \
"else; " \
"  set fdt_high 0x; " \
"  set initrd_high 0x; " \
-   "  smhload ${kernel_name} ${kernel_addr}; " \
-   "  smhload ${fdtfile} ${fdt_addr}; " \
-   "  smhload ${initrd_name} ${initrd_addr} "\
-   "  initrd_end; " \
-   "  fdt addr ${fdt_addr}; fdt resize; " \
-   "  fdt chosen ${initrd_addr} ${initrd_end}; " \
-   "  booti $kernel_addr - $fdt_addr; " \
+   "  smhload ${kernel_name} ${kernel_addr_r}; " \
+   "  smhload ${fdtfile} ${fdt_addr_r}; " \
+   "  smhload ${ramdisk_name} ${ramdisk_addr_r} "\
+   "  ramdisk_end; " \
+   "  fdt addr ${fdt_addr_r}; fdt resize; " \
+   "  if test -n ${ramdisk_end}; then "\
+   "fdt chosen ${ramdisk_addr_r} 
${ramdisk_end}; " \
+   "  else; " \
+   "fdt chosen; " \
+   "  fi; " \
+   "  booti $kernel_addr_r - $fdt_addr_r; " \
"fi"
 #endif
 
-- 
2.25.1



[PATCH v2 2/5] vexpress64: Refactor header file to make it easier to add new FVPs

2021-11-11 Thread Peter Hoyes
From: Peter Hoyes 

Rename from vexpress_aemv8a.h -> vepxress_aemv8.h as new FVPs may not be
v8-A. No change in behavior.

This is towards future work to enable support for the FVP_BaseR.

Signed-off-by: Peter Hoyes 
---
 board/armltd/vexpress64/Kconfig   |  2 +-
 doc/README.semihosting|  2 +-
 .../{vexpress_aemv8a.h => vexpress_aemv8.h}   | 48 ++-
 3 files changed, 27 insertions(+), 25 deletions(-)
 rename include/configs/{vexpress_aemv8a.h => vexpress_aemv8.h} (88%)

diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig
index 1d13f542e6..4aab3f092e 100644
--- a/board/armltd/vexpress64/Kconfig
+++ b/board/armltd/vexpress64/Kconfig
@@ -7,7 +7,7 @@ config SYS_VENDOR
default "armltd"
 
 config SYS_CONFIG_NAME
-   default "vexpress_aemv8a"
+   default "vexpress_aemv8"
 
 config JUNO_DTB_PART
string "NOR flash partition holding DTB"
diff --git a/doc/README.semihosting b/doc/README.semihosting
index c01bed..f382d0131e 100644
--- a/doc/README.semihosting
+++ b/doc/README.semihosting
@@ -25,7 +25,7 @@ or turning on CONFIG_BASE_FVP for the more full featured 
model.
 Rather than create a new armv8 board similar to armltd/vexpress64, add
 semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING
 and CONFIG_BASE_FVP both set. Also reuse the existing board config file
-vexpress_aemv8a.h but differentiate the two models by the presence or
+vexpress_aemv8.h but differentiate the two models by the presence or
 absence of CONFIG_BASE_FVP. This change is tested and works on both the
 Foundation and Base fastmodel simulators.
 
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8.h
similarity index 88%
rename from include/configs/vexpress_aemv8a.h
rename to include/configs/vexpress_aemv8.h
index df22584d9a..49517a60b0 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8.h
@@ -4,36 +4,37 @@
  *   configurations.
  */
 
-#ifndef __VEXPRESS_AEMV8A_H
-#define __VEXPRESS_AEMV8A_H
+#ifndef __VEXPRESS_AEMV8_H
+#define __VEXPRESS_AEMV8_H
 
 #define CONFIG_REMAKE_ELF
 
 /* Link Definitions */
-#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
+#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
+#else
 /* ATF loads u-boot here for BASE_FVP model */
 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0)
-#elif CONFIG_TARGET_VEXPRESS64_JUNO
-#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
 #endif
 
 #define CONFIG_SYS_BOOTM_LEN (64 << 20)  /* Increase max gunzip size */
 
 /* CS register bases for the original memory map. */
-#define V2M_PA_CS0 0x
-#define V2M_PA_CS1 0x1400
-#define V2M_PA_CS2 0x1800
-#define V2M_PA_CS3 0x1c00
-#define V2M_PA_CS4 0x0c00
-#define V2M_PA_CS5 0x1000
+#define V2M_BASE   0x8000
+#define V2M_PA_BASE0x
+
+#define V2M_PA_CS0 (V2M_PA_BASE + 0x)
+#define V2M_PA_CS1 (V2M_PA_BASE + 0x1400)
+#define V2M_PA_CS2 (V2M_PA_BASE + 0x1800)
+#define V2M_PA_CS3 (V2M_PA_BASE + 0x1c00)
+#define V2M_PA_CS4 (V2M_PA_BASE + 0x0c00)
+#define V2M_PA_CS5 (V2M_PA_BASE + 0x1000)
 
 #define V2M_PERIPH_OFFSET(x)   (x << 16)
 #define V2M_SYSREGS(V2M_PA_CS3 + V2M_PERIPH_OFFSET(1))
 #define V2M_SYSCTL (V2M_PA_CS3 + V2M_PERIPH_OFFSET(2))
 #define V2M_SERIAL_BUS_PCI (V2M_PA_CS3 + V2M_PERIPH_OFFSET(3))
 
-#define V2M_BASE   0x8000
-
 /* Common peripherals relative to CS7. */
 #define V2M_AACI   (V2M_PA_CS3 + V2M_PERIPH_OFFSET(4))
 #define V2M_MMCI   (V2M_PA_CS3 + V2M_PERIPH_OFFSET(5))
@@ -72,23 +73,23 @@
 
 /* Generic Interrupt Controller Definitions */
 #ifdef CONFIG_GICV3
-#define GICD_BASE  (0x2f00)
-#define GICR_BASE  (0x2f10)
+#define GICD_BASE  (V2M_PA_BASE + 0x2f00)
+#define GICR_BASE  (V2M_PA_BASE + 0x2f10)
 #else
 
-#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
-#define GICD_BASE  (0x2f00)
-#define GICC_BASE  (0x2c00)
-#elif CONFIG_TARGET_VEXPRESS64_JUNO
+#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
 #define GICD_BASE  (0x2C01)
 #define GICC_BASE  (0x2C02f000)
+#else
+#define GICD_BASE  (V2M_PA_BASE + 0x2f00)
+#define GICC_BASE  (V2M_PA_BASE + 0x2c00)
 #endif
 #endif /* !CONFIG_GICV3 */
 
 #ifndef CONFIG_TARGET_VEXPRESS64_JUNO
 /* The Vexpress64 simulators use SMSC91C111 */

[PATCH v2 1/5] doc: Add documentation for the Arm VExpress64 board configs

2021-11-11 Thread Peter Hoyes
From: Peter Hoyes 

Create a new documentation section for Arm Ltd boards with a sub-page
for the VExpress64 boards (FVP-A and Juno).

Signed-off-by: Peter Hoyes 
---
 doc/board/armltd/index.rst  |  9 ++
 doc/board/armltd/vexpress64.rst | 51 +
 doc/board/index.rst |  1 +
 3 files changed, 61 insertions(+)
 create mode 100644 doc/board/armltd/index.rst
 create mode 100644 doc/board/armltd/vexpress64.rst

diff --git a/doc/board/armltd/index.rst b/doc/board/armltd/index.rst
new file mode 100644
index 00..c20d8a0a26
--- /dev/null
+++ b/doc/board/armltd/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Arm Ltd
+=
+
+.. toctree::
+   :maxdepth: 2
+
+   vexpress64.rst
diff --git a/doc/board/armltd/vexpress64.rst b/doc/board/armltd/vexpress64.rst
new file mode 100644
index 00..d87b1c38f5
--- /dev/null
+++ b/doc/board/armltd/vexpress64.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Arm Versatile Express
+=
+
+The vexpress_* board configuration supports the following platforms:
+
+ * FVP_Base_RevC-2xAEMvA
+ * Juno development board
+
+Fixed Virtual Platforms
+---
+
+The Fixed Virtual Platforms (FVP) are complete simulations of an Arm system,
+including processor, memory and peripherals. They are set out in a 
"programmer's
+view", which gives a comprehensive model on which to build and test software.
+
+The supported FVPs are available free of charge and can be downloaded from the
+Arm developer site [1]_ (user registration might be required).
+
+Supported features:
+
+ * GICv3
+ * Generic timer
+ * PL011 UART
+
+The default configuration assumes that U-Boot is bootstrapped using a suitable
+bootloader, such as Trusted Firmware-A [4]_. The u-boot binary can be passed
+into the TF-A build: ``make PLAT= all fip BL33=u-boot.bin``
+
+The FVPs can be debugged using Arm Development Studio [2]_.
+
+Juno
+
+
+Juno is an Arm development board with the following features:
+
+ * Arm Cortex-A72/A57 and Arm Cortex-A53 in a "big.LITTLE" configuration
+ * A PCIe Gen2.0 bus with 4 lanes
+ * 8GB of DRAM
+ * GICv2
+
+More details can be found in the board documentation [3]_.
+
+References
+--
+
+.. [1] 
https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
+.. [2] 
https://developer.arm.com/tools-and-software/embedded/arm-development-studio
+.. [3] 
https://developer.arm.com/tools-and-software/development-boards/juno-development-board
+.. [4] https://trustedfirmware-a.readthedocs.io/
\ No newline at end of file
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 74ea33e081..78b486538b 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -11,6 +11,7 @@ Board-specific doc
AndesTech/index
amlogic/index
apple/index
+   armltd/index
atmel/index
congatec/index
coreboot/index
-- 
2.25.1



[PATCH v2 0/5] VExpress64 board family improvements

2021-11-11 Thread Peter Hoyes
From: Peter Hoyes 

These patches add the follow improvements to the VExpress64 board family
(BASE_FVP and Juno):

 * Add documentation
 * Allow use of OF_BOARD for BASE_FVP (off by default)
 * Allow use of the virtio-net driver (off by default)
 * Refactor header file to make it easier to add new FVPs with similar
 * memory layouts
 * Fix issue where fdt is called with invalid arguments during BASE_FVP
   boot
 * Update BASE_FVP env vars to recommended names

This is towards future work to add support for the
FVP_BaseR_AEMv8R.

Changes in v2:
 * Add note about building U-Boot with TF-A to FVP doc
 * Modify BASE_FVP env var addresses to allow space for larger kernels
 * OF_BOARD cleanups

Peter Hoyes (5):
  doc: Add documentation for the Arm VExpress64 board configs
  vexpress64: Refactor header file to make it easier to add new FVPs
  vexpress64: Clean up BASE_FVP boot configuration
  vexpress64: Enable OF_CONTROL and OF_BOARD for VExpress64
  vexpress64: Enable VIRTIO_NET network driver

 board/armltd/vexpress64/Kconfig   |   2 +-
 board/armltd/vexpress64/Makefile  |   2 +-
 board/armltd/vexpress64/lowlevel_init.S   |  12 +++
 board/armltd/vexpress64/vexpress64.c  |  33 ++
 doc/README.semihosting|   2 +-
 doc/board/armltd/index.rst|   9 ++
 doc/board/armltd/vexpress64.rst   |  51 +
 doc/board/index.rst   |   1 +
 .../{vexpress_aemv8a.h => vexpress_aemv8.h}   | 102 ++
 9 files changed, 167 insertions(+), 47 deletions(-)
 create mode 100644 board/armltd/vexpress64/lowlevel_init.S
 create mode 100644 doc/board/armltd/index.rst
 create mode 100644 doc/board/armltd/vexpress64.rst
 rename include/configs/{vexpress_aemv8a.h => vexpress_aemv8.h} (72%)

-- 
2.25.1



Re: [PATCH] net: uclass: Save ethernet MAC address when generated

2021-11-11 Thread Michael Walle

Hi Ramon,

Am 2021-11-09 14:55, schrieb Michael Walle:

Am 2021-11-04 22:00, schrieb Ramon Fried:


What's the verdict ? We're keeping this patch ?


There was a good point from Grygorii: linux might deal
in its own way with missing ethernet addresses (and warn
the user about it because its usually an error).

And IMHO that net list can be fixed in a different way.

If this patch is accepted, it should be clearly documented
in the Kconfig help text. And as I said, it changes behavior.



So this patch now in your pull request. Why are you even asking
then?

-michael


Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-11 Thread Padmarao Begari
Hi Bin,

On Thu, Nov 11, 2021 at 1:37 PM Bin Meng  wrote:

> Hi Padmarao,
>
> On Thu, Nov 11, 2021 at 2:11 PM  wrote:
> >
> > Hi Bin,
> >
> >
> >
> > Do we need to upstream Linux kernel bindings for Microchip MACB
> compatible if there is no change in Linux MACB driver?
> >
> > Are the Linux maintainers can approve this? Because the changes only in
> U-Boot not Linux.
> >
>
> If Linux driver does not need to be updated to support MPFS macb using
> existing compatible string but U-Boot driver has to, something is
> wrong on the U-Boot macb driver side.
>
> Would you please reconsider the whole changes?
>
>
We submitted patches(v1, v2) last year for the U-Boot MACB update for
64-bit DMA access same like Linux MACB driver using "#ifdef
CONFIG_DMA_ADDR_T_64BIT" but one of the reviewer wanted to check 64-bit DMA
support at runtime instead of #ifdef and we updated the macb driver based
on the design config debug6 register of MACB hardware which supports 32-bit
or 64-bit DMA in patch(v3) but the SiFive FU540 MACB didn't work then the
reviewer suggested use compatible string instead of design config register
and updated same in patch(v4), these changes were tested and acknowledged
them at Patch v6.

Below links for patch submitted for "net: macb: Add DMA 64-bit address
support for macb"

https://www.mail-archive.com/u-boot@lists.denx.de/msg387528.html - Patch v2
https://www.mail-archive.com/u-boot@lists.denx.de/msg389490.html - Patch v3
https://www.mail-archive.com/u-boot@lists.denx.de/msg390611.html - Patch v4
https://www.mail-archive.com/u-boot@lists.denx.de/msg391001.html - Patch v5
https://www.mail-archive.com/u-boot@lists.denx.de/msg391850.html - Patch v6

Regards
Padmarao

Regards,
> Bin
>


[PATCH 2/2] test_vboot.py: include test of fdt_add_pubkey tool

2021-11-11 Thread Roman Kopytin
Signed-off-by: Roman Kopytin 
Cc: Rasmus Villemoes 
---
 test/py/tests/test_vboot.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
index 095e00cce3..0e9b158e00 100644
--- a/test/py/tests/test_vboot.py
+++ b/test/py/tests/test_vboot.py
@@ -232,6 +232,13 @@ def test_vboot(u_boot_console, name, sha_algo, padding, 
sign_options, required,
 
 util.run_and_log(cons, [fit_check_sign, '-f', fit, '-k', dtb])
 
+# Create a fresh .dtb without the public keys
+dtc('sandbox-u-boot.dts')
+# Then add the dev key via the fdt_add_pubkey tool
+util.run_and_log(cons, [fdt_add_pubkey, '-a', '%s,rsa2048' % sha_algo,
+'-k', tmpdir, '-n', 'dev', '-r', 'conf', dtb])
+util.run_and_log(cons, [fit_check_sign, '-f', fit, '-k', dtb])
+
 if full_test:
 # Make sure that U-Boot checks that the config is in the list of
 # hashed nodes. If it isn't, a security bypass is possible.
@@ -373,6 +380,7 @@ def test_vboot(u_boot_console, name, sha_algo, padding, 
sign_options, required,
 fit = '%stest.fit' % tmpdir
 mkimage = cons.config.build_dir + '/tools/mkimage'
 fit_check_sign = cons.config.build_dir + '/tools/fit_check_sign'
+fdt_add_pubkey = cons.config.build_dir + '/tools/fdt_add_pubkey'
 dtc_args = '-I dts -O dtb -i %s' % tmpdir
 dtb = '%ssandbox-u-boot.dtb' % tmpdir
 sig_node = '/configurations/conf-1/signature'
-- 
2.25.1



[PATCH 1/2] tools: add fdt_add_pubkey

2021-11-11 Thread Roman Kopytin
Having to use the -K option to mkimage to populate U-Boot's .dtb with the
public key while signing the kernel FIT image is often a little
awkward. In particular, when using a meta-build system such as
bitbake/Yocto, having the tasks of the kernel and U-Boot recipes
intertwined, modifying deployed artifacts and rebuilding U-Boot with
an updated .dtb is quite cumbersome. Also, in some scenarios one may
wish to build U-Boot complete with the public key(s) embedded in the
.dtb without the corresponding private keys being present on the same
build host.

So this adds a simple tool that allows one to disentangle the kernel
and U-Boot builds, by simply copy-pasting just enough of the mkimage
code to allow one to add a public key to a .dtb. When using mkimage,
some of the information is taken from the .its used to build the
kernel (algorithm and key name), so that of course needs to be
supplied on the command line.

Signed-off-by: Roman Kopytin 
Cc: Rasmus Villemoes 
---
 tools/.gitignore   |   1 +
 tools/Makefile |   3 +
 tools/fdt_add_pubkey.c | 130 +
 3 files changed, 134 insertions(+)
 create mode 100644 tools/fdt_add_pubkey.c

diff --git a/tools/.gitignore b/tools/.gitignore
index a88453f64d..f312b760e4 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -6,6 +6,7 @@
 /dumpimage
 /easylogo/easylogo
 /envcrc
+/fdt_add_pubkey
 /fdtgrep
 /file2include
 /fit_check_sign
diff --git a/tools/Makefile b/tools/Makefile
index b45219e2c3..c142c48e73 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -73,6 +73,7 @@ mkenvimage-objs := mkenvimage.o os_support.o lib/crc32.o
 
 hostprogs-y += dumpimage mkimage
 hostprogs-$(CONFIG_TOOLS_LIBCRYPTO) += fit_info fit_check_sign
+hostprogs-$(CONFIG_TOOLS_LIBCRYPTO) += fdt_add_pubkey
 
 hostprogs-$(CONFIG_CMD_BOOTEFI_SELFTEST) += file2include
 
@@ -154,6 +155,7 @@ dumpimage-objs := $(dumpimage-mkimage-objs) dumpimage.o
 mkimage-objs   := $(dumpimage-mkimage-objs) mkimage.o
 fit_info-objs   := $(dumpimage-mkimage-objs) fit_info.o
 fit_check_sign-objs   := $(dumpimage-mkimage-objs) fit_check_sign.o
+fdt_add_pubkey-objs   := $(dumpimage-mkimage-objs) fdt_add_pubkey.o
 file2include-objs := file2include.o
 
 ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_TOOLS_LIBCRYPTO),)
@@ -191,6 +193,7 @@ HOSTCFLAGS_fit_image.o += 
-DMKIMAGE_DTC=\"$(CONFIG_MKIMAGE_DTC_PATH)\"
 HOSTLDLIBS_dumpimage := $(HOSTLDLIBS_mkimage)
 HOSTLDLIBS_fit_info := $(HOSTLDLIBS_mkimage)
 HOSTLDLIBS_fit_check_sign := $(HOSTLDLIBS_mkimage)
+HOSTLDLIBS_fdt_add_pubkey := $(HOSTLDLIBS_mkimage)
 
 hostprogs-$(CONFIG_EXYNOS5250) += mkexynosspl
 hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
diff --git a/tools/fdt_add_pubkey.c b/tools/fdt_add_pubkey.c
new file mode 100644
index 00..96099312e4
--- /dev/null
+++ b/tools/fdt_add_pubkey.c
@@ -0,0 +1,130 @@
+#include 
+#include "fit_common.h"
+
+static const char *cmdname;
+
+static const char *algo_name = "sha1,rsa2048"; /* -a  */
+static const char *keydir = "."; /* -k  */
+static const char *keyname = "key"; /* -n  */
+static const char *require_keys; /* -r  */
+static const char *keydest; /* argv[n] */
+
+static void print_usage(const char *msg)
+{
+   fprintf(stderr, "Error: %s\n", msg);
+   fprintf(stderr, "Usage: %s [-a ] [-k ] [-n ] [-r 
] \n",
+   cmdname);
+   fprintf(stderr, "Help information: %s [-h]\n", cmdname);
+   exit(EXIT_FAILURE);
+}
+
+static void print_help()
+{
+   fprintf(stderr, "Options:\n"
+   "\t-aCryptographic algorithm. Optional parameter, 
default value: sha1,rsa2048\n"
+   "\t-k  Directory with public key. Optional 
parameter, default value: .\n"
+   "\t-n Public key name. Optional parameter, default 
value: key\n"
+   "\t-r  Required: If present this indicates that the 
key must be verified for the image / configuration to be considered valid.\n"
+   "\t  FDT blob file for adding of the public key. 
Required parameter.\n");
+   exit(EXIT_FAILURE);
+}
+
+static void process_args(int argc, char *argv[])
+{
+   int opt;
+
+   while((opt = getopt(argc, argv, "a:k:n:r:h")) != -1) {
+   switch (opt) {
+   case 'k':
+   keydir = optarg;
+   break;
+   case 'a':
+   algo_name = optarg;
+   break;
+   case 'n':
+   keyname = optarg;
+   break;
+   case 'r':
+   require_keys = optarg;
+   break;
+   case 'h':
+   print_help();
+   default:
+   print_usage("Invalid option");
+   }
+   }
+   /* The last parameter is expected to be the .dtb to add the public key 
to */
+   if (optind < argc)
+   keydest = argv[optind];
+
+   if (!keydest)
+   print_usag

[PATCH 0/2] RFC: add fdt_add_pubkey tool

2021-11-11 Thread Roman Kopytin
In order to reduce the coupling between building the kernel and
U-Boot, I'd like a tool that can add a public key to U-Boot's dtb
without simultaneously signing a FIT image. That tool doesn't seem to
exist, so I stole the necessary pieces from mkimage et al and put it
in a single .c file.

I'm still working on the details of my proposed "require just k out
these n required keys" and how it should be implemented, but it will
probably involve teaching this tool a bunch of new options. These
patches are not necessarily ready for inclusion (unless someone else
finds fdt_add_pubkey useful as is), but I thought I might as well send
it out for early comments.

Roman Kopytin (2):
  tools: add fdt_add_pubkey
  test_vboot.py: include test of fdt_add_pubkey tool

 test/py/tests/test_vboot.py |   8 +++
 tools/.gitignore|   1 +
 tools/Makefile  |   3 +
 tools/fdt_add_pubkey.c  | 130 
 4 files changed, 142 insertions(+)
 create mode 100644 tools/fdt_add_pubkey.c

-- 
2.25.1



Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-11 Thread Bin Meng
Hi Padmarao,

On Thu, Nov 11, 2021 at 2:11 PM  wrote:
>
> Hi Bin,
>
>
>
> Do we need to upstream Linux kernel bindings for Microchip MACB compatible if 
> there is no change in Linux MACB driver?
>
> Are the Linux maintainers can approve this? Because the changes only in 
> U-Boot not Linux.
>

If Linux driver does not need to be updated to support MPFS macb using
existing compatible string but U-Boot driver has to, something is
wrong on the U-Boot macb driver side.

Would you please reconsider the whole changes?

Regards,
Bin