Re: [U-Boot] [PATCH v3 2/2] arm64: zynqmp: add tool to convert PMU config object .c to binary

[Luca Ceresoli]

Hi Michal,

On 04/05/19 00:31, Michal Simek wrote:
> Hi,
> 
> On 15. 04. 19 9:47, Luca Ceresoli wrote:
>> The recently-added ZYNQMP_LOAD_PM_CFG_OBJ_FILE option allows SPL to load a
>> PMUFW configuration object from a binary blob. However the configuration
>> object is produced by Xilinx proprietary tools as a C source file and no
>> tool exists to easily convert it to a binary blob in an embedded Linux
>> build system for U-Boot to use.
>>
>> Add a simple Python script to do the conversion.
>>
>> It is definitely not a complete C language parser, but it is enough to
>> parse the known patterns generated by Xilinx tools, including:
>>
>>  - defines
>>  - literal integers, optionally with a 'U' suffix
>>  - bitwise OR between them
>>
>> Signed-off-by: Luca Ceresoli 
>> ---
>>  arch/arm/mach-zynqmp/pm_cfg_obj_convert.py | 302 +
>>  1 file changed, 302 insertions(+)
>>  create mode 100755 arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
>>
>> diff --git a/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py 
>> b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
>> new file mode 100755
>> index ..5aea15860319
>> --- /dev/null
>> +++ b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
>> @@ -0,0 +1,302 @@
>> +#!/usr/bin/env python3
>> +# SPDX-License-Identifier: GPL-2.0+
>> +# Copyright (C) 2019 Luca Ceresoli 
>> +
>> +import sys
>> +import re
>> +import struct
>> +import logging
>> +import argparse
>> +
>> +parser = argparse.ArgumentParser(
>> +description='Convert a PMU configuration object from C source to a 
>> binary blob.',
>> +allow_abbrev=False)
>> +parser.add_argument('-D', '--debug', action="store_true")
>> +parser.add_argument(
>> +"in_file", metavar='INPUT_FILE',
>> +help='PMU configuration object (C source as produced by Xilinx XSDK)')
>> +parser.add_argument(
>> +"out_file", metavar='OUTPUT_FILE',
>> +help='PMU configuration object binary blob')
>> +args = parser.parse_args()
>> +
>> +logging.basicConfig(format='%(levelname)s:%(message)s',
>> +level=(logging.DEBUG if args.debug else 
>> logging.WARNING))
>> +
>> +pm_define = {
>> +'PM_CAP_ACCESS'   : 0x1,
>> +'PM_CAP_CONTEXT'  : 0x2,
>> +'PM_CAP_WAKEUP'   : 0x4,
>> +
>> +'NODE_UNKNOWN':  0,
>> +'NODE_APU':  1,
>> +'NODE_APU_0'  :  2,
>> +'NODE_APU_1'  :  3,
>> +'NODE_APU_2'  :  4,
>> +'NODE_APU_3'  :  5,
>> +'NODE_RPU':  6,
>> +'NODE_RPU_0'  :  7,
>> +'NODE_RPU_1'  :  8,
>> +'NODE_PLD':  9,
>> +'NODE_FPD': 10,
>> +'NODE_OCM_BANK_0' : 11,
>> +'NODE_OCM_BANK_1' : 12,
>> +'NODE_OCM_BANK_2' : 13,
>> +'NODE_OCM_BANK_3' : 14,
>> +'NODE_TCM_0_A': 15,
>> +'NODE_TCM_0_B': 16,
>> +'NODE_TCM_1_A': 17,
>> +'NODE_TCM_1_B': 18,
>> +'NODE_L2' : 19,
>> +'NODE_GPU_PP_0'   : 20,
>> +'NODE_GPU_PP_1'   : 21,
>> +'NODE_USB_0'  : 22,
>> +'NODE_USB_1'  : 23,
>> +'NODE_TTC_0'  : 24,
>> +'NODE_TTC_1'  : 25,
>> +'NODE_TTC_2'  : 26,
>> +'NODE_TTC_3'  : 27,
>> +'NODE_SATA'   : 28,
>> +'NODE_ETH_0'  : 29,
>> +'NODE_ETH_1'  : 30,
>> +'NODE_ETH_2'  : 31,
>> +'NODE_ETH_3'  : 32,
>> +'NODE_UART_0' : 33,
>> +'NODE_UART_1' : 34,
>> +'NODE_SPI_0'  : 35,
>> +'NODE_SPI_1'  : 36,
>> +'NODE_I2C_0'  : 37,
>> +'NODE_I2C_1'  : 38,
>> +'NODE_SD_0'   : 39,
>> +'NODE_SD_1'   : 40,
>> +'NODE_DP' : 41,
>> +'NODE_GDMA'   : 42,
>> +'NODE_ADMA'   : 43,
>> +'NODE_NAND'   : 44,
>> +'NODE_QSPI'   : 45,
>> +'NODE_GPIO'   : 46,
>> +'NODE_CAN_0'  : 47,
>> +'NODE_CAN_1'  : 48,
>> +'NODE_EXTERN' : 49,
>> +'NODE_APLL'   : 50,
>> +'NODE_VPLL'   : 51,
>> +'NODE_DPLL'   : 52,
>> +'NODE_RPLL'   : 53,
>> +'NODE_IOPLL'  : 54,
>> +'NODE_DDR': 55,
>> +'NODE_IPI_APU': 56,
>> +'NODE_IPI_RPU_0'  : 57,
>> +'NODE_GPU': 58,
>> +'NODE_PCIE'   : 59,
>> +'NODE_PCAP'   : 60,
>> +'NODE_RTC': 61,
>> +'NODE_LPD': 62,
>> +'NODE_VCU': 63,
>> +'NODE_IPI_RPU_1'  : 64,
>> +'NODE_IPI_PL_0'   : 65,
>> +'NODE_IPI_PL_1'   : 66,
>> +'NODE_IPI_PL_2'   : 67,
>> +'NODE_IPI_PL_3'   : 68,
>> +'NODE_PL' : 69,
>> +'NODE_ID_MA'  : 70,
>> +
>> +'XILPM_RESET_PCIE_CFG' : 1000,
>> +'XILPM_RESET_PCIE_BRIDGE'  : 1001,
>> +'XILPM_RESET_PCIE_CTRL': 1002,
>> +'XILPM_RESET_DP'   : 1003,
>> +'XILPM_RESET_SWDT_CRF' : 1004,
>> +'XILPM_RESET_AFI_FM5'  : 1005,
>> +'XILPM_RESET_AFI_FM4'  : 1006,
>> +'XILPM_RESET_AFI_FM3'  : 1007,
>> +'XILPM_RESET_AFI_FM2'  : 1008,
>> +'XILPM_RESET_AFI_FM1'  : 1009,
>> +'XILPM_RESET_AFI_FM0'

Re: [U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine

[Anup Patel]

Hi Karsten,

I tried again with image header changes applied to u-boot and
Linux kernel but still not able to reproduce the issues.

Either you might have more local changes or debian toolchain
is causing issue for u-boot.

Here are the logs

anup@anup-ubuntu64:~/Work/riscv-test$ qemu-system-riscv64 -nographic
-machine virt -m 2G \
> -kernel opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \
> -device loader,file=u-boot/u-boot.bin,addr=0x8020 \
> -object rng-random,filename=/dev/urandom,id=rng0 \
> -device virtio-rng-device,rng=rng0 \
> -append "console=ttyS0 rw root=/dev/vda1" \
> -device virtio-blk-device,drive=hd0 \
> -drive file=./rootfs_riscv64.ext2,format=raw,id=hd0 \
> -device virtio-net-device,netdev=usernet \
> -netdev user,id=usernet,hostfwd=tcp::2-:22

OpenSBI v0.3 (May  4 2019 09:17:54)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 100 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1-1-g93789509a3 (May 04 2019 - 08:58:04 +0530)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  2 GiB
In:uart@1000
Out:   uart@1000
Err:   uart@1000
Net:
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot:  0

Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 32.0 MB = 0.0 GB (65536 x 512)
... is now current device
** No partition table - virtio 0 **
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (3 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8210
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (3 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8100
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=>
=>
=> QEMU 3.1.92 monitor - type 'help' for more information
(qemu) q




anup@anup-ubuntu64:~/Work/riscv-test$ qemu-system-riscv64 -nographic
-smp 2 -machine virt -m 1.9G -kernel
opensbi/build/platform/qemu/virt/firmware/fw_payload.elf -device
loader,file=build-riscv64/arch/riscv/boot/Image,addr=0x8100
-object rng-random,filename=/dev/urandom,id=rng0 -device
virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda"
-device virtio-blk-device,drive=hd0 -drive
file=./rootfs_riscv64.ext2,format=raw,id=hd0 -device
virtio-net-device,netdev=usernet -netdev
user,id=usernet,hostfwd=tcp::2-:22

OpenSBI v0.3 (May  4 2019 09:17:54)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 104 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1-1-g93789509a3 (May 04 2019 - 08:58:04 +0530)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  1.9 GiB
In:uart@1000
Out:   uart@1000
Err:   uart@1000
Net:
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot:  0

Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 32.0 MB = 0.0 GB (65536 x 512)
... is now current device
** No partition table - virtio 0 **
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (7 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8210
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (1 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8100
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=>
=>
=> booti ${kernel_addr_r} - ${fdtcontroladdr}
## Flattened Device Tree blob at f9134f90
   Booting using the fdt blob at 0xf9134f90
   Using Device Tree in place at f9134f90, end f9138d9d

Starting kernel ...

[0.00] OF: fdt: Ignoring memory range 0x80

[U-Boot] [PATCH] Make FIT support really optional

[Fabrice Fontaine]

Due to some mistakes in the source code, it was not possible to really
turn FIT support off. This commit fixes the problem by means of the
following changes:

- Enclose "bootm_host_load_image" and "bootm_host_load_images" between
  checks for CONFIG_FIT_SIGNATURE, in common/bootm.c.

- Enclose the declaration of "bootm_host_load_images" between checks for
  CONFIG_FIT_SIGNATURE, in common/bootm.h.

- Condition the compilation and linking of fit_common.o fit_image.o
  image-host.o common/image-fit.o to CONFIG_FIT=y, in tools/Makefile.

Signed-off-by: Carlos Santos 
[fabio: adapt for 2016.07]
Signed-off-by: Fabio Estevam 
[Ricardo: fix conditional compilation and linking of the files mentioned above
for 2016.07]
Signed-off-by: Ricardo Martincoski 
[Jörg: adapt for 2019.01]
Signed-off-by: Jörg Krause 
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/uboot-tools/0003-Make-FIT-support-really-optional.patch]
Signed-off-by: Fabrice Fontaine 
---
 common/bootm.c  | 2 ++
 include/bootm.h | 2 ++
 tools/Makefile  | 6 ++
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index b5d37d38db..d193751647 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -924,6 +924,7 @@ void memmove_wd(void *to, void *from, size_t len, ulong 
chunksz)
memmove(to, from, len);
 }
 
+#if defined(CONFIG_FIT_SIGNATURE)
 static int bootm_host_load_image(const void *fit, int req_image_type)
 {
const char *fit_uname_config = NULL;
@@ -988,5 +989,6 @@ int bootm_host_load_images(const void *fit, int cfg_noffset)
/* Return the first error we found */
return err;
 }
+#endif
 
 #endif /* ndef USE_HOSTCC */
diff --git a/include/bootm.h b/include/bootm.h
index e2cc6d4b99..f771b733f5 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -42,7 +42,9 @@ void lynxkdi_boot(image_header_t *hdr);
 
 boot_os_fn *bootm_os_get_boot_func(int os);
 
+#if defined(CONFIG_FIT_SIGNATURE)
 int bootm_host_load_images(const void *fit, int cfg_noffset);
+#endif
 
 int boot_selected_os(int argc, char * const argv[], int state,
 bootm_headers_t *images, boot_os_fn *boot_fn);
diff --git a/tools/Makefile b/tools/Makefile
index eadeba417d..e2f572cae1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -58,6 +58,7 @@ hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info fit_check_sign
 
 hostprogs-$(CONFIG_CMD_BOOTEFI_SELFTEST) += file2include
 
+FIT_OBJS-$(CONFIG_FIT) := fit_common.o fit_image.o image-host.o 
common/image-fit.o
 FIT_SIG_OBJS-$(CONFIG_FIT_SIGNATURE) := common/image-sig.o
 
 # The following files are synced with upstream DTC.
@@ -80,16 +81,13 @@ ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
 # common objs for dumpimage and mkimage
 dumpimage-mkimage-objs := aisimage.o \
atmelimage.o \
+   $(FIT_OBJS-y) \
$(FIT_SIG_OBJS-y) \
common/bootm.o \
lib/crc32.o \
default_image.o \
lib/fdtdec_common.o \
lib/fdtdec.o \
-   fit_common.o \
-   fit_image.o \
-   common/image-fit.o \
-   image-host.o \
common/image.o \
imagetool.o \
imximage.o \
-- 
2.20.1

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

Re: [U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine

[Anup Patel]

Hi Karsten,

First of all, the 2GB case where U-Boot crashes shows that U-Boot is
trying to access memory close to 0x8000 where OpenSBI firmware
is running hence it gets ACCESS fault. The OpenSBI protects firmware
using PMP configuration whereas BBL does not. In fact, it is very easy
to corrupt BBL from S-mode.

In fact, the U-Boot crashes with OpenSBI implies that issue in U-Boot
which OpenSBI is helping us detect by injecting ACCESS fault to S-mode.

I tries vanilla U-Boot-2019.07-rc1 (without booti support) and OpenSBI
at commit f9643f34. It worked fine for me. Here's the boot log:

anup@anup-ubuntu64:~/Work/riscv-test$ qemu-system-riscv64 -nographic
-machine virt -m 2G \
> -kernel opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \
> -device loader,file=u-boot/u-boot.bin,addr=0x8020 \
> -object rng-random,filename=/dev/urandom,id=rng0 \
> -device virtio-rng-device,rng=rng0 \
> -append "console=ttyS0 rw root=/dev/vda1" \
> -device virtio-blk-device,drive=hd0 \
> -drive file=./rootfs_riscv64.ext2,format=raw,id=hd0 \
> -device virtio-net-device,netdev=usernet \
> -netdev user,id=usernet,hostfwd=tcp::2-:22

OpenSBI v0.3 (May  4 2019 08:27:41)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 100 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1 (May 04 2019 - 07:50:53 +0530)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  2 GiB
In:uart@1000
Out:   uart@1000
Err:   uart@1000
Net:
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot:  0
=>
=> setenv ipaddr 10.0.2.1
=> ping 10.0.2.2
Using virtio-net#2 device
host 10.0.2.2 is alive
=>
Using virtio-net#2 device
host 10.0.2.2 is alive
=>
Using virtio-net#2 device
host 10.0.2.2 is alive
=>
Using virtio-net#2 device
host 10.0.2.2 is alive
=> 
=> QEMU 3.1.92 monitor - type 'help' for more information
(qemu) q


I also tried OpenSBI fail cases you reported but using bootm
and this worked for me as well.

Create temp.bin:
./u-boot/tools/mkimage -A riscv -O linux -T kernel -C none -a
0x8020 -e 0x8020 -n Linux -d
build-riscv64/arch/riscv/boot/Image
build-riscv64/arch/riscv/boot/uImage
./u-boot/tools/mkimage -A riscv -O linux -T ramdisk -C none -a
0x -n "Linux RootFS" -d rootfs_riscv64.img uRamdisk
dd if=/dev/zero of=./temp.bin bs=1M count=1
dd if=./build-riscv64/arch/riscv/boot/uImage of=./temp.bin bs=1M
seek=1 conv=nocreat,notrunc
dd if=./uRamdisk of=./temp.bin bs=1M seek=33 conv=nocreat,notrunc

Here's the log:
anup@anup-ubuntu64:~/Work/riscv-test$ qemu-system-riscv64 -nographic
-smp 2 -machine virt -m 1.9G -kernel
opensbi/build/platform/qemu/virt/firmware/fw_payload.elf -device
loader,file=./temp.bin,addr=0x8050 -object
rng-random,filename=/dev/urandom,id=rng0 -device
virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda"
-device virtio-blk-device,drive=hd0 -drive
file=./rootfs_riscv64.ext2,format=raw,id=hd0 -device
virtio-net-device,netdev=usernet -netdev
user,id=usernet,hostfwd=tcp::2-:22

OpenSBI v0.3 (May  4 2019 08:27:41)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 104 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1 (May 04 2019 - 07:50:53 +0530)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  1.9 GiB
In:uart@1000
Out:   uart@1000
Err:   uart@1000
Net:
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot:  0

Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 32.0 MB = 0.0 GB (65536 x 512)
... is now current device
** No partition table - virtio 0 **
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (6 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8210
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (0 ms)
Using virtio-

[U-Boot] Pull request for mmc sub-system for v2019.07

[Peng Fan]

Hi Tom,

I am not able to setup ssh to denx mmc tree, so use my github for this 
request-pull,
please see whether this is ok for you.
Please pull mmc-2019-5-3 for v2019.07-rc1
Travis build: https://travis-ci.org/MrVan/u-boot/builds/527760370

Thanks,
Peng.

The following changes since commit b4ee6daad7a2604ca9466b2ba48de86cc27d381f:

  Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx (2019-05-01 
07:25:51 -0400)

are available in the Git repository at:

  https://github.com/MrVan/u-boot.git tags/mmc-2019-5-3

for you to fetch changes up to 37cb626da25d0d895079c85866d0c2030cd98438:

  mmc: sdhci: Add Support for ADMA2 (2019-05-03 20:44:11 +0800)


- adma support for sdhci
- a few fixes to fsl_esdhc

Faiz Abbas (2):
  mmc: sdhci: Move DMA handling to prepare_dma() function
  mmc: sdhci: Add Support for ADMA2

Ye Li (2):
  mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issue
  mmc: fsl_esdhc: Fix wp_enable issue

 drivers/mmc/Kconfig |  14 
 drivers/mmc/fsl_esdhc.c |  41 +
 drivers/mmc/sdhci.c | 188 
++---
 include/sdhci.h |  44 +++
 4 files changed, 233 insertions(+), 54 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/6] dm: pci: add Freescale PowerPC PCIe driver

[Z.q. Hou]

From: Hou Zhiqiang 

Add PCIe DM driver for Freescale PowerPC PCIe controllers.

Signed-off-by: Hou Zhiqiang 
---
 drivers/pci/Kconfig  |   7 +
 drivers/pci/Makefile |   1 +
 drivers/pci/pcie_fsl.c   | 612 +++
 drivers/pci/pcie_fsl.h   |  60 
 drivers/pci/pcie_fsl_fixup.c |  40 +++
 5 files changed, 720 insertions(+)
 create mode 100644 drivers/pci/pcie_fsl.c
 create mode 100644 drivers/pci/pcie_fsl.h
 create mode 100644 drivers/pci/pcie_fsl_fixup.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 1521885bde..36674db6c1 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -60,6 +60,13 @@ config PCIE_DW_MVEBU
  Armada-8K SoCs. The PCIe controller on Armada-8K is based on
  DesignWare hardware.
 
+config PCIE_FSL
+   bool "FSL PowerPC PCIe support"
+   depends on DM_PCI
+   help
+ Say Y here if you want to enable PCIe controller support on
+ FSL PowerPC series SoCs.
+
 config PCI_RCAR_GEN2
bool "Renesas RCar Gen2 PCIe driver"
depends on DM_PCI
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 4923641895..d984848266 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_SH7780_PCI) +=pci_sh7780.o
 obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
 obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
 obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
+obj-$(CONFIG_PCIE_FSL) += pcie_fsl.o pcie_fsl_fixup.o
 obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
 obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape_fixup.o
 obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o
diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
new file mode 100644
index 00..95973fd8d9
--- /dev/null
+++ b/drivers/pci/pcie_fsl.c
@@ -0,0 +1,612 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 NXP
+ * Copyright 2007-2012 Freescale Semiconductor, Inc.
+ *
+ * PCIe DM U-Boot driver for Freescale PowerPC SoCs
+ * Author: Hou Zhiqiang 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pcie_fsl.h"
+
+LIST_HEAD(fsl_pcie_list);
+
+static inline int fsl_pcie_link_up(struct fsl_pcie *pcie);
+
+static int fsl_pcie_addr_valid(struct fsl_pcie *pcie, pci_dev_t bdf)
+{
+   struct udevice *bus = pcie->bus;
+
+   if (!pcie->enabled)
+   return -ENXIO;
+
+   if (PCI_BUS(bdf) < bus->seq)
+   return -EINVAL;
+
+   if (PCI_BUS(bdf) > bus->seq && (!fsl_pcie_link_up(pcie) || pcie->mode))
+   return -EINVAL;
+
+   if (PCI_BUS(bdf) == bus->seq && (PCI_DEV(bdf) > 0 || PCI_FUNC(bdf) > 0))
+   return -EINVAL;
+
+   if (PCI_BUS(bdf) == (bus->seq + 1) && (PCI_DEV(bdf) > 0))
+   return -EINVAL;
+
+   return 0;
+}
+
+static int fsl_pcie_read_config(struct udevice *bus, pci_dev_t bdf,
+   uint offset, ulong *valuep,
+   enum pci_size_t size)
+{
+   struct fsl_pcie *pcie = dev_get_priv(bus);
+   ccsr_fsl_pci_t *regs = pcie->regs;
+   u32 val;
+
+   if (fsl_pcie_addr_valid(pcie, bdf)) {
+   *valuep = pci_get_ff(size);
+   return 0;
+   }
+
+   bdf = bdf - PCI_BDF(bus->seq, 0, 0);
+   val = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
+   out_be32(®s->cfg_addr, val);
+
+   sync();
+
+   switch (size) {
+   case PCI_SIZE_8:
+   *valuep = in_8((u8 *)®s->cfg_data + (offset & 3));
+   break;
+   case PCI_SIZE_16:
+   *valuep = in_le16((u16 *)((u8 *)®s->cfg_data +
+ (offset & 2)));
+   break;
+   case PCI_SIZE_32:
+   *valuep = in_le32(®s->cfg_data);
+   break;
+   }
+
+   return 0;
+}
+
+static int fsl_pcie_write_config(struct udevice *bus, pci_dev_t bdf,
+uint offset, ulong value,
+enum pci_size_t size)
+{
+   struct fsl_pcie *pcie = dev_get_priv(bus);
+   ccsr_fsl_pci_t *regs = pcie->regs;
+   u32 val;
+   u8 val_8;
+   u16 val_16;
+   u32 val_32;
+
+   if (fsl_pcie_addr_valid(pcie, bdf))
+   return 0;
+
+   bdf = bdf - PCI_BDF(bus->seq, 0, 0);
+   val = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
+   out_be32(®s->cfg_addr, val);
+
+   sync();
+
+   switch (size) {
+   case PCI_SIZE_8:
+   val_8 = value;
+   out_8((u8 *)®s->cfg_data + (offset & 3), val_8);
+   break;
+   case PCI_SIZE_16:
+   val_16 = value;
+   out_le16((u16 *)((u8 *)®s->cfg_data + (offset & 2)), val_16);
+   break;
+   case PCI_SIZE_32:
+   val_32 = value;
+   out_le32(®s->cfg_data, val_32);
+   break;
+   }
+
+   return 0;
+}
+
+static int fsl_pcie_hose_read

[U-Boot] [PATCH 3/6] t2080: dts: Added PCIe DT nodes

[Z.q. Hou]

From: Hou Zhiqiang 

T2080 integrated 4 PCIe controllers, which is compatible with
the PCI Express™ Base Specification, Revision 3.0, and this
patch is to add DT node for each PCIe controller.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/t2080.dtsi | 48 +
 1 file changed, 48 insertions(+)

diff --git a/arch/powerpc/dts/t2080.dtsi b/arch/powerpc/dts/t2080.dtsi
index db65ea5725..89b2c618ae 100644
--- a/arch/powerpc/dts/t2080.dtsi
+++ b/arch/powerpc/dts/t2080.dtsi
@@ -59,4 +59,52 @@
clock-frequency = <0x0>;
};
};
+
+   pcie@ffe24 {
+   compatible = "fsl,pcie-t2080", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe24 0x0 0x4000>;   /* registers */
+   law_trgt_if = <0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf800 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x 0x0 
0x2000>; /* non-prefetchable memory */
+   };
+
+   pcie@ffe25 {
+   compatible = "fsl,pcie-t2080", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe25 0x0 0x1000>;   /* registers */
+   law_trgt_if = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf801 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x2000 0x0 
0x1000>; /* non-prefetchable memory */
+   };
+
+   pcie@ffe26 {
+   compatible = "fsl,pcie-t2080", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe26 0x0 0x1000>;   /* registers */
+   law_trgt_if = <2>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf802 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x3000 0x0 
0x1000>; /* non-prefetchable memory */
+   };
+
+   pcie@ffe27 {
+   compatible = "fsl,pcie-t2080", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe27 0x0 0x1000>;   /* registers */
+   law_trgt_if = <3>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf803 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x4000 0x0 
0x1000>; /* non-prefetchable memory */
+   };
 };
-- 
2.17.1

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

[U-Boot] [PATCH 5/6] powerpc: T208xQDS: Disable legacy PCIe driver

[Z.q. Hou]

From: Hou Zhiqiang 

Disable legacy PCIe driver and remove unused PCIe macros.

Signed-off-by: Hou Zhiqiang 
---
 include/configs/T208xQDS.h | 18 --
 1 file changed, 18 deletions(-)

diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index 9ca384cc0c..c414081ca5 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -508,49 +508,31 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_PCIE3   /* PCIE controller 3 */
 #define CONFIG_PCIE4   /* PCIE controller 4 */
 #define CONFIG_FSL_PCIE_RESET   /* pcie reset fix link width 2x-4x*/
-#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
 #define CONFIG_SYS_PCI_64BIT   /* enable 64-bit PCI resources */
 /* controller 1, direct to uli, tgtid 3, Base address 2 */
 #define CONFIG_SYS_PCIE1_MEM_VIRT  0x8000
-#define CONFIG_SYS_PCIE1_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE1_MEM_PHYS  0xcull
-#define CONFIG_SYS_PCIE1_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE1_IO_VIRT   0xf800
-#define CONFIG_SYS_PCIE1_IO_BUS0x
 #define CONFIG_SYS_PCIE1_IO_PHYS   0xff800ull
-#define CONFIG_SYS_PCIE1_IO_SIZE   0x0001  /* 64k */
 
 /* controller 2, Slot 2, tgtid 2, Base address 201000 */
 #define CONFIG_SYS_PCIE2_MEM_VIRT  0xa000
-#define CONFIG_SYS_PCIE2_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE2_MEM_PHYS  0xc2000ull
-#define CONFIG_SYS_PCIE2_MEM_SIZE  0x1000 /* 256M */
 #define CONFIG_SYS_PCIE2_IO_VIRT   0xf801
-#define CONFIG_SYS_PCIE2_IO_BUS0x
 #define CONFIG_SYS_PCIE2_IO_PHYS   0xff801ull
-#define CONFIG_SYS_PCIE2_IO_SIZE   0x0001  /* 64k */
 
 /* controller 3, Slot 1, tgtid 1, Base address 202000 */
 #define CONFIG_SYS_PCIE3_MEM_VIRT  0xb000
-#define CONFIG_SYS_PCIE3_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE3_MEM_PHYS  0xc3000ull
-#define CONFIG_SYS_PCIE3_MEM_SIZE  0x1000  /* 256M */
 #define CONFIG_SYS_PCIE3_IO_VIRT   0xf802
-#define CONFIG_SYS_PCIE3_IO_BUS0x
 #define CONFIG_SYS_PCIE3_IO_PHYS   0xff802ull
-#define CONFIG_SYS_PCIE3_IO_SIZE   0x0001  /* 64k */
 
 /* controller 4, Base address 203000 */
 #define CONFIG_SYS_PCIE4_MEM_VIRT   0xc000
-#define CONFIG_SYS_PCIE4_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE4_MEM_PHYS  0xc4000ull
-#define CONFIG_SYS_PCIE4_MEM_SIZE  0x1000  /* 256M */
-#define CONFIG_SYS_PCIE4_IO_BUS0x
 #define CONFIG_SYS_PCIE4_IO_PHYS   0xff803ull
-#define CONFIG_SYS_PCIE4_IO_SIZE   0x0001  /* 64k */
 
 #ifdef CONFIG_PCI
-#define CONFIG_PCI_INDIRECT_BRIDGE
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
 #endif
 
-- 
2.17.1

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

[U-Boot] [PATCH 2/6] powerpc: T208xQDS: Compile the legacy PCIe routines conditionally

[Z.q. Hou]

From: Hou Zhiqiang 

Compile the legacy PCIe initialization reoutines only when DM_PCI
is not enabled.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/t208xqds/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/freescale/t208xqds/pci.c b/board/freescale/t208xqds/pci.c
index c761aea0ac..ef26f14c46 100644
--- a/board/freescale/t208xqds/pci.c
+++ b/board/freescale/t208xqds/pci.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#if !defined(CONFIG_DM_PCI)
 void pci_init_board(void)
 {
fsl_pcie_init_board(0);
@@ -20,3 +21,4 @@ void pci_of_setup(void *blob, bd_t *bd)
 {
FT_FSL_PCI_SETUP;
 }
+#endif
-- 
2.17.1

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

[U-Boot] [PATCH 6/6] configs: T2080QDS: Enable PCIe driver

[Z.q. Hou]

From: Hou Zhiqiang 

Signed-off-by: Hou Zhiqiang 
---
 configs/T2080QDS_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/T2080QDS_defconfig b/configs/T2080QDS_defconfig
index 79cf4424b4..b7fdd3ffb4 100644
--- a/configs/T2080QDS_defconfig
+++ b/configs/T2080QDS_defconfig
@@ -3,6 +3,7 @@ CONFIG_SYS_TEXT_BASE=0xEFF4
 CONFIG_MPC85xx=y
 CONFIG_TARGET_T2080QDS=y
 CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
+# CONFIG_SYS_MALLOC_F is not set
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
@@ -28,6 +29,7 @@ 
CONFIG_MTDPARTS_DEFAULT="mtdparts=fe800.nor:1m(uboot),5m(kernel),128k(dtb),9
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="t2080qds"
 CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_DM=y
 CONFIG_FSL_CAAM=y
 CONFIG_FSL_ESDHC=y
 CONFIG_MTD_NOR_FLASH=y
@@ -43,6 +45,9 @@ CONFIG_PHYLIB=y
 CONFIG_PHY_AQUANTIA=y
 CONFIG_E1000=y
 CONFIG_MII=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
-- 
2.17.1

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

[U-Boot] [PATCH 1/6] powerpc: mpc85xx: Update the condition to compile PCI routines

[Z.q. Hou]

From: Hou Zhiqiang 

Compile the routines of mpc85xx/pci.c when both FSL_PCI_INIT
and DM_PCI are not enabled.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/cpu/mpc85xx/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/cpu/mpc85xx/pci.c b/arch/powerpc/cpu/mpc85xx/pci.c
index 90ccc3427c..1d0213a513 100644
--- a/arch/powerpc/cpu/mpc85xx/pci.c
+++ b/arch/powerpc/cpu/mpc85xx/pci.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-#if !defined(CONFIG_FSL_PCI_INIT)
+#if !defined(CONFIG_FSL_PCI_INIT) && !defined(CONFIG_DM_PCI)
 
 #ifndef CONFIG_SYS_PCI1_MEM_BUS
 #define CONFIG_SYS_PCI1_MEM_BUS CONFIG_SYS_PCI1_MEM_BASE
-- 
2.17.1

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

[U-Boot] [PATCH 0/6] dm: pci: add Freescale PowerPC PCIe driver

[Z.q. Hou]

From: Hou Zhiqiang 

Add PCIe DM driver for Freescale PowerPC PCIe controllers.

Hou Zhiqiang (6):
  powerpc: mpc85xx: Update the condition to compile PCI routines
  powerpc: T208xQDS: Compile the legacy PCIe routines conditionally
  t2080: dts: Added PCIe DT nodes
  dm: pci: add Freescale PowerPC PCIe driver
  powerpc: T208xQDS: Disable legacy PCIe driver
  configs: T2080QDS: Enable PCIe driver

 arch/powerpc/cpu/mpc85xx/pci.c |   2 +-
 arch/powerpc/dts/t2080.dtsi|  48 +++
 board/freescale/t208xqds/pci.c |   2 +
 configs/T2080QDS_defconfig |   5 +
 drivers/pci/Kconfig|   7 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pcie_fsl.c | 612 +
 drivers/pci/pcie_fsl.h |  60 
 drivers/pci/pcie_fsl_fixup.c   |  40 +++
 include/configs/T208xQDS.h |  18 -
 10 files changed, 776 insertions(+), 19 deletions(-)
 create mode 100644 drivers/pci/pcie_fsl.c
 create mode 100644 drivers/pci/pcie_fsl.h
 create mode 100644 drivers/pci/pcie_fsl_fixup.c

-- 
2.17.1

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

[U-Boot] [PATCH v2 4/4] MAINTAINERS: Update lib/optee with my details

[Bryan O'Donoghue]

Commit 32ce6179fb99 ("optee: Add lib entries for sharing OPTEE code across
ports") adds code into lib/optee but neglects to update MAINTAINERS to make
me buggable for questions and maintenance.

Signed-off-by: Bryan O'Donoghue 
Suggested-by: Jens Wiklander 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 09f31cd483..ee97c0fe28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -761,6 +761,11 @@ F: drivers/tee/
 F: include/tee.h
 F: include/tee/
 
+TEE-lib
+M: Bryan O'Donoghue 
+S: Maintained
+F: lib/optee
+
 UBI
 M: Kyungmin Park 
 M: Heiko Schocher 
-- 
2.21.0

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

[U-Boot] [PATCH v2 3/4] warp7: configs: bl33: Tidy up OPTEE defines

[Bryan O'Donoghue]

When booting in BL33 mode i.e. with u-boot loaded by OP-TEE we get the
following print-out.

Board: WARP7 in secure mode OPTEE DRAM 0xa000-0xa000

This is incorrect the right range is 0x9e00-0xa000. This patch
fixes the defines on the warp7_bl33_defconfig file to tidy up the output.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
---
 configs/warp7_bl33_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index 300dc3805a..735c85c0a3 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -53,4 +53,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
 CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
-CONFIG_OPTEE_TZDRAM_SIZE=0x200
+CONFIG_OPTEE=y
+CONFIG_OPTEE_TZDRAM_BASE=0x9e00
+CONFIG_OPTEE_TZDRAM_SIZE=0x0200
-- 
2.21.0

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

[U-Boot] [PATCH v2 2/4] warp7: include: configs: Skip low-level init if BOOTM_OPTEE false

[Bryan O'Donoghue]

Commit c7b3a7ee5351 ("optee: adjust dependencies and default values for
dram") wants to skip low-level init of i.MX7 hardware in the case where
OP-TEE has already run and u-boot is being run as BL33 in normal world.

Currently we check for both #ifdef CONFIG_OPTEE_TZDRAM_SIZE and #ifndef
CONFIG_OPTEE to determine if lowlevel init should be skipped, however, in
order to ensure non-OPTEE users never see OPTEE related defines we cannot
rely on this method.

Fortunately we can use CONFIG_BOOTM_OPTEE for the same purpose.
CONFIG_BOOTM_OPTEE is only relevant if you want u-boot to load OP-TEE not
if u-boot has already been loaded by OP-TEE.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
Cc: Breno Lima 
Cc: Rui Miguel Silva 
Acked-by: Rui Miguel Silva 
---
 include/configs/warp7.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 37649cf2c5..06e2e97d5e 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -18,11 +18,9 @@
  * launched by OPTEE, because of that we shall skip all the low level
  * initialization since it was already done by ATF or OPTEE
  */
-#ifdef CONFIG_OPTEE_TZDRAM_SIZE
-#ifndef CONFIG_OPTEE
+#ifndef CONFIG_BOOTM_OPTEE
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #endif
-#endif
 
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (35 * SZ_1M)
-- 
2.21.0

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

[U-Boot] [PATCH v2 1/4] optee: Make TZDRAM config options contingent on CONFIG_OPTEE

[Bryan O'Donoghue]

Commit c7b3a7ee5351 ("optee: adjust dependencies and default values for
dram") makes the TZDRAM defines for OPTEE show up for all configs as a
side-effect. While not harmful its not what we really want.

This patch makes the following defines contingent on CONFIG_OPTEE=y

CONFIG_OPTEE_TZDRAM_BASE
CONFIG_OPTEE_TZDRAM_SIZE

Rightly, if you don't have CONFIG_OPTEE=y you don't care about the above
two defines.

Signed-off-by: Bryan O'Donoghue 
Cc: Rui Miguel Silva 
Acked-by: Rui Miguel Silva 
---
 lib/optee/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/optee/Kconfig b/lib/optee/Kconfig
index 3773d89c31..c398f9b953 100644
--- a/lib/optee/Kconfig
+++ b/lib/optee/Kconfig
@@ -17,6 +17,7 @@ config OPTEE_LOAD_ADDR
 config OPTEE_TZDRAM_SIZE
hex "Amount of Trust-Zone RAM for the OPTEE image"
default 0x000
+   depends on OPTEE
help
  The size of pre-allocated Trust Zone DRAM to allocate for the OPTEE
  runtime.
@@ -24,6 +25,7 @@ config OPTEE_TZDRAM_SIZE
 config OPTEE_TZDRAM_BASE
hex "Base address of Trust-Zone RAM for the OPTEE image"
default 0x
+   depends on OPTEE
help
  The base address of pre-allocated Trust Zone DRAM for
  the OPTEE runtime.
-- 
2.21.0

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

[U-Boot] [PATCH v2 0/4] Tidy up some dangling OP-TEE gotchas

[Bryan O'Donoghue]

Tom, Stefano.

Any chance of getting this set applied to one of your respective trees ?

V2:
Add Acked/Reviewed-by Rui as indicated

V1:

Robert P Day rightly pointed out that some odd OP-TEE specific defines were
appearing in his defconfig, despite not having CONFIG_OPTEE=y set in his
defconfig.

Looking into this with a small bit of restructure we can fix this corner
case.

- Make sure OP-TEE CONFIG options only appear when you are compiling for
  OPTEE
- Fix WaRP7 BL33 so that the low-level init skipping routines can tolerate
  the afore mentioned change.
- Update MAINTAINERS with my own details so that questions pertaining to
  lib/optee comes my way.

Bryan O'Donoghue (4):
  optee: Make TZDRAM config options contingent on CONFIG_OPTEE
  warp7: include: configs: Skip low-level init if BOOTM_OPTEE false
  warp7: configs: bl33: Tidy up OPTEE defines
  MAINTAINERS: Update lib/optee with my details

 MAINTAINERS  | 5 +
 configs/warp7_bl33_defconfig | 4 +++-
 include/configs/warp7.h  | 4 +---
 lib/optee/Kconfig| 2 ++
 4 files changed, 11 insertions(+), 4 deletions(-)

-- 
2.21.0

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

Re: [U-Boot] [PATCH v3 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime

[Michal Simek]

On 15. 04. 19 9:47, Luca Ceresoli wrote:
> Optionally allow U-Boot to load at the PMU firmware configuration object
> into the Power Management Unit (PMU) on Xilinx ZynqMP.
> 
> The configuration object is required by the PMU FW to enable most SoC
> peripherals. So far the only way to boot using U-Boot SPL was to hard-code
> the configuration object in the PMU firmware. Allow a different boot
> process, where the PMU FW is equal for any ZynqMP chip and its
> configuration is passed at runtime by U-Boot SPL.
> 
> All the code for Inter-processor communication with the PMU is isolated in
> a new file (pmu_ipc.c). The code is inspired by the same feature as
> implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
> Firmware:
> 
>  * 
> https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
>  * 
> https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357
> 
> SPL logs on the console before loading the configuration object:
> 
>   U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21)
>   Loading PMUFW cfg obj (2008 bytes)
>   EL Level:   EL3
>   ...
> 
> Signed-off-by: Luca Ceresoli 
> 
> ---
> 
> Changes RFC v2 -> v3:
>  - don't compile pm_cfg_obj.c from source, load it from a binary file
>(suggested by Michal)
>  - move IPC code to arch/arm/mach-zynqmp/ and sys_proto.h (Michal)
> 
> Changes RFC v1 -> RFC v2:
>  - Load the cfg_obj in SPL, not U-Boot proper: this required a complete
>reimplementation since we cannot rely on ATF now
>  - Update and refine the Kconfig option help
> ---
>  arch/arm/mach-zynqmp/Kconfig  |  17 +++
>  arch/arm/mach-zynqmp/Makefile |   4 +
>  arch/arm/mach-zynqmp/include/mach/sys_proto.h |   4 +
>  arch/arm/mach-zynqmp/pmu_ipc.c| 112 ++
>  board/xilinx/zynqmp/Makefile  |  12 ++
>  board/xilinx/zynqmp/pm_cfg_obj.S  |  17 +++
>  board/xilinx/zynqmp/zynqmp.c  |   8 ++
>  7 files changed, 174 insertions(+)
>  create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c
>  create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S
> 
> diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
> index 9bb5a5c20201..b88d1d313839 100644
> --- a/arch/arm/mach-zynqmp/Kconfig
> +++ b/arch/arm/mach-zynqmp/Kconfig
> @@ -65,6 +65,23 @@ config PMUFW_INIT_FILE
> Include external PMUFW (Platform Management Unit FirmWare) to
> a Xilinx bootable image (boot.bin).
>  
> +config ZYNQMP_LOAD_PM_CFG_OBJ_FILE
> + string "PMU firmware configuration object to load at runtime"
> + help
> +

remove this empty line.

> +   Path to a binary PMU firmware configuration object to be linked
> +   into U-Boot SPL and loaded at runtime into the PMU firmware.
> +
> +   The ZynqMP Power Management Unit (PMU) needs a configuration
> +   object for most SoC peripherals to work. To have it loaded by
> +   U-Boot SPL set here the file name (absolute path or relative to
> +   board/xilinx/zynqmp/) of your configuration, which must be a
> +   binary blob. It will be linked in the SPL binary and loaded into
> +   the PMU firmware by U-Boot SPL during board initialization.
> +
> +   Leave this option empty if your PMU firmware has a hard-coded
> +   configuration object or you are loading it by any other means.
> +
>  config ZYNQMP_USB
>   bool "Configure ZynqMP USB"
>  
> diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile
> index 8a3b0747244a..d391b7c1d54e 100644
> --- a/arch/arm/mach-zynqmp/Makefile
> +++ b/arch/arm/mach-zynqmp/Makefile
> @@ -8,3 +8,7 @@ obj-y += cpu.o
>  obj-$(CONFIG_MP) += mp.o
>  obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o
>  obj-$(CONFIG_ZYNQMP_PSU_INIT_ENABLED)+= psu_spl_init.o
> +
> +ifneq ($(CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE),"")
> +obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o
> +endif
> diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h 
> b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
> index 385c8825f2f6..e2b9a79ed539 100644
> --- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
> +++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
> @@ -72,4 +72,8 @@ int chip_id(unsigned char id);
>  void tcm_init(u8 mode);
>  #endif
>  
> +#if defined(CONFIG_SPL_BUILD) && defined(ZYNQMP_LOAD_PM_CFG_OBJ)
> +void zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size);
> +#endif

nit: you can remove that if/endif to open a way to also pass different
configuration object from full u-boot.

> +
>  #endif /* _ASM_ARCH_SYS_PROTO_H */
> diff --git a/arch/arm/mach-zynqmp/pmu_ipc.c b/arch/arm/mach-zynqmp/pmu_ipc.c
> new file mode 100644
> index ..5feb8568f8de
> --- /dev/null
> +++ b/arch/arm/mach-zynqmp/pmu_ipc.c
> @@ -0,0 +1,112 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Inter-Processor Communication w

Re: [U-Boot] [PATCH v3 2/2] arm64: zynqmp: add tool to convert PMU config object .c to binary

[Michal Simek]

Hi,

On 15. 04. 19 9:47, Luca Ceresoli wrote:
> The recently-added ZYNQMP_LOAD_PM_CFG_OBJ_FILE option allows SPL to load a
> PMUFW configuration object from a binary blob. However the configuration
> object is produced by Xilinx proprietary tools as a C source file and no
> tool exists to easily convert it to a binary blob in an embedded Linux
> build system for U-Boot to use.
> 
> Add a simple Python script to do the conversion.
> 
> It is definitely not a complete C language parser, but it is enough to
> parse the known patterns generated by Xilinx tools, including:
> 
>  - defines
>  - literal integers, optionally with a 'U' suffix
>  - bitwise OR between them
> 
> Signed-off-by: Luca Ceresoli 
> ---
>  arch/arm/mach-zynqmp/pm_cfg_obj_convert.py | 302 +
>  1 file changed, 302 insertions(+)
>  create mode 100755 arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
> 
> diff --git a/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py 
> b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
> new file mode 100755
> index ..5aea15860319
> --- /dev/null
> +++ b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
> @@ -0,0 +1,302 @@
> +#!/usr/bin/env python3
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2019 Luca Ceresoli 
> +
> +import sys
> +import re
> +import struct
> +import logging
> +import argparse
> +
> +parser = argparse.ArgumentParser(
> +description='Convert a PMU configuration object from C source to a 
> binary blob.',
> +allow_abbrev=False)
> +parser.add_argument('-D', '--debug', action="store_true")
> +parser.add_argument(
> +"in_file", metavar='INPUT_FILE',
> +help='PMU configuration object (C source as produced by Xilinx XSDK)')
> +parser.add_argument(
> +"out_file", metavar='OUTPUT_FILE',
> +help='PMU configuration object binary blob')
> +args = parser.parse_args()
> +
> +logging.basicConfig(format='%(levelname)s:%(message)s',
> +level=(logging.DEBUG if args.debug else logging.WARNING))
> +
> +pm_define = {
> +'PM_CAP_ACCESS'   : 0x1,
> +'PM_CAP_CONTEXT'  : 0x2,
> +'PM_CAP_WAKEUP'   : 0x4,
> +
> +'NODE_UNKNOWN':  0,
> +'NODE_APU':  1,
> +'NODE_APU_0'  :  2,
> +'NODE_APU_1'  :  3,
> +'NODE_APU_2'  :  4,
> +'NODE_APU_3'  :  5,
> +'NODE_RPU':  6,
> +'NODE_RPU_0'  :  7,
> +'NODE_RPU_1'  :  8,
> +'NODE_PLD':  9,
> +'NODE_FPD': 10,
> +'NODE_OCM_BANK_0' : 11,
> +'NODE_OCM_BANK_1' : 12,
> +'NODE_OCM_BANK_2' : 13,
> +'NODE_OCM_BANK_3' : 14,
> +'NODE_TCM_0_A': 15,
> +'NODE_TCM_0_B': 16,
> +'NODE_TCM_1_A': 17,
> +'NODE_TCM_1_B': 18,
> +'NODE_L2' : 19,
> +'NODE_GPU_PP_0'   : 20,
> +'NODE_GPU_PP_1'   : 21,
> +'NODE_USB_0'  : 22,
> +'NODE_USB_1'  : 23,
> +'NODE_TTC_0'  : 24,
> +'NODE_TTC_1'  : 25,
> +'NODE_TTC_2'  : 26,
> +'NODE_TTC_3'  : 27,
> +'NODE_SATA'   : 28,
> +'NODE_ETH_0'  : 29,
> +'NODE_ETH_1'  : 30,
> +'NODE_ETH_2'  : 31,
> +'NODE_ETH_3'  : 32,
> +'NODE_UART_0' : 33,
> +'NODE_UART_1' : 34,
> +'NODE_SPI_0'  : 35,
> +'NODE_SPI_1'  : 36,
> +'NODE_I2C_0'  : 37,
> +'NODE_I2C_1'  : 38,
> +'NODE_SD_0'   : 39,
> +'NODE_SD_1'   : 40,
> +'NODE_DP' : 41,
> +'NODE_GDMA'   : 42,
> +'NODE_ADMA'   : 43,
> +'NODE_NAND'   : 44,
> +'NODE_QSPI'   : 45,
> +'NODE_GPIO'   : 46,
> +'NODE_CAN_0'  : 47,
> +'NODE_CAN_1'  : 48,
> +'NODE_EXTERN' : 49,
> +'NODE_APLL'   : 50,
> +'NODE_VPLL'   : 51,
> +'NODE_DPLL'   : 52,
> +'NODE_RPLL'   : 53,
> +'NODE_IOPLL'  : 54,
> +'NODE_DDR': 55,
> +'NODE_IPI_APU': 56,
> +'NODE_IPI_RPU_0'  : 57,
> +'NODE_GPU': 58,
> +'NODE_PCIE'   : 59,
> +'NODE_PCAP'   : 60,
> +'NODE_RTC': 61,
> +'NODE_LPD': 62,
> +'NODE_VCU': 63,
> +'NODE_IPI_RPU_1'  : 64,
> +'NODE_IPI_PL_0'   : 65,
> +'NODE_IPI_PL_1'   : 66,
> +'NODE_IPI_PL_2'   : 67,
> +'NODE_IPI_PL_3'   : 68,
> +'NODE_PL' : 69,
> +'NODE_ID_MA'  : 70,
> +
> +'XILPM_RESET_PCIE_CFG' : 1000,
> +'XILPM_RESET_PCIE_BRIDGE'  : 1001,
> +'XILPM_RESET_PCIE_CTRL': 1002,
> +'XILPM_RESET_DP'   : 1003,
> +'XILPM_RESET_SWDT_CRF' : 1004,
> +'XILPM_RESET_AFI_FM5'  : 1005,
> +'XILPM_RESET_AFI_FM4'  : 1006,
> +'XILPM_RESET_AFI_FM3'  : 1007,
> +'XILPM_RESET_AFI_FM2'  : 1008,
> +'XILPM_RESET_AFI_FM1'  : 1009,
> +'XILPM_RESET_AFI_FM0'  : 1010,
> +'XILPM_RESET_GDMA' : 1011,
> +'XILPM_RESET_GPU_PP1'  : 1012,
> +'XILPM_RESET_GPU_PP0'  : 1013,
> +'XILPM_RESET_GPU'  : 10

[U-Boot] [PATCH] Fix spelling of available.

[Vagrant Cascadian]

Signed-off-by: Vagrant Cascadian 
---

 arch/x86/Kconfig  | 2 +-
 arch/x86/cpu/i386/interrupt.c | 2 +-
 arch/x86/lib/fsp/fsp_common.c | 2 +-
 common/spl/Kconfig| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e052093775..7dc7c15c7d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -415,7 +415,7 @@ config ENABLE_MRC_CACHE
  For platforms that use Intel FSP for the memory initialization,
  please check FSP output HOB via U-Boot command 'fsp hob' to see
  if there is FSP_NON_VOLATILE_STORAGE_HOB_GUID (asm/fsp/fsp_hob.h).
- If such GUID does not exist, MRC cache is not avaiable on such
+ If such GUID does not exist, MRC cache is not available on such
  platform (eg: Intel Queensbay), which means selecting this option
  here does not make any difference.
 
diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
index 1ea415b876..47df3172b7 100644
--- a/arch/x86/cpu/i386/interrupt.c
+++ b/arch/x86/cpu/i386/interrupt.c
@@ -37,7 +37,7 @@ static char *exceptions[] = {
"Overflow",
"BOUND Range Exceeded",
"Invalid Opcode (Undefined Opcode)",
-   "Device Not Avaiable (No Math Coprocessor)",
+   "Device Not Available (No Math Coprocessor)",
"Double Fault",
"Coprocessor Segment Overrun",
"Invalid TSS",
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index d5ed1d5631..ed0827c6e9 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -138,7 +138,7 @@ int arch_fsp_init(void)
}
 
/*
-* DM is not avaiable yet at this point, hence call
+* DM is not available yet at this point, hence call
 * CMOS access library which does not depend on DM.
 */
stack = cmos_read32(CMOS_FSP_STACK_ADDR);
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index dd078fe79d..c7cd34449a 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -282,7 +282,7 @@ config SPL_SHA1_SUPPORT
  checksum is a 160-bit (20-byte) hash value used to check that the
  image contents have not been corrupted or maliciously altered.
  While SHA1 is fairly secure it is coming to the end of its life
- due to the expanding computing power avaiable to brute-force
+ due to the expanding computing power available to brute-force
  attacks. For more security, consider SHA256.
 
 config SPL_SHA256_SUPPORT
-- 
2.20.1

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

Re: [U-Boot] [PATCH v2] imx: Use a convenient default value for SYS_MALLOC_F_LEN

[Auer, Lukas]

On Fri, 2019-05-03 at 14:05 -0300, Fabio Estevam wrote:
> Commit 3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to
> simple-bus driver") causes some i.MX boards that were converted
> to DM, such as warp7, to fail to boot.
> 
> As explained by Lukas Auer:
> 
> "With the patch, U-Boot probes the drivers for devices under simple-bus
> device tree nodes in the pre-relocation device model. The default value
> of CONFIG_SYS_MALLOC_F_LEN (0x400) leaves U-Boot with not enough memory to
> do this, causing it to hang."
> 
> Fix this problem by providing a convenient default value for
> CONFIG_SYS_MALLOC_F_LEN.
> 
> Reported-by: Pierre-Jean Texier 
> Suggested-by: Lukas Auer 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v1:
> - Move the default setting to the main Kconfig and make it depend
> on i.MX
> 
>  Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 

Thank you for sending the patch!

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

[U-Boot] [PATCH 1/1] arm: mvebu: Add CRS305-1G-4S board

[Luka Kovacic]

CRS305-1G-4S has a switch chip with an integrated CPU (98DX3236) and
like some of the other simillar boards requires bin_hdr.
bin_hdr (DDR3 init stage) is currently retrieved from the stock
bootloader and compiled into the kwb image.

Adds support for U-Boot, enable UART, SPI, Winbond SPI flash chip
support and writing env to SPI flash.

arch/arm/dts: Remove unused parameters in DTS for crs305-1g-4s

arch/arm/mach-mvebu: Set the proper processor for crs305-1g-4s
(98DX3236)

board/mikrotik/crs305-1g-4s: Enable CONFIG_DISPLAY_BOARDINFO

board/mikrotik/crs305-1g-4s: Remove GPIO1 (Reset Button)

Signed-off-by: Luka Kovacic 
---
 arch/arm/dts/Makefile |   3 +-
 .../dts/armada-xp-crs305-1g-4s-u-boot.dtsi|  13 +++
 arch/arm/dts/armada-xp-crs305-1g-4s.dts   | 110 ++
 arch/arm/mach-mvebu/Kconfig   |   7 ++
 board/mikrotik/crs305-1g-4s/.gitignore|   1 +
 board/mikrotik/crs305-1g-4s/MAINTAINERS   |   7 ++
 board/mikrotik/crs305-1g-4s/Makefile  |  14 +++
 board/mikrotik/crs305-1g-4s/README|  23 
 board/mikrotik/crs305-1g-4s/binary.0  |  11 ++
 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c|  71 +++
 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in   |  12 ++
 configs/crs305-1g-4s_defconfig|  52 +
 include/configs/crs305-1g-4s.h|  37 ++
 13 files changed, 360 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s.dts
 create mode 100644 board/mikrotik/crs305-1g-4s/.gitignore
 create mode 100644 board/mikrotik/crs305-1g-4s/MAINTAINERS
 create mode 100644 board/mikrotik/crs305-1g-4s/Makefile
 create mode 100644 board/mikrotik/crs305-1g-4s/README
 create mode 100644 board/mikrotik/crs305-1g-4s/binary.0
 create mode 100644 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c
 create mode 100644 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in
 create mode 100644 configs/crs305-1g-4s_defconfig
 create mode 100644 include/configs/crs305-1g-4s.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8e082f2840..8d73bcb57f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -162,7 +162,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-38x-controlcenterdc.dtb  \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb   \
-   armada-xp-db-xc3-24g4xg.dtb
+   armada-xp-db-xc3-24g4xg.dtb \
+   armada-xp-crs305-1g-4s.dtb
 
 dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \
uniphier-ld11-global.dtb \
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi 
b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
new file mode 100644
index 00..8576a02730
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+&uart0 {
+   u-boot,dm-pre-reloc;
+};
+
+&spi0 {
+   u-boot,dm-pre-reloc;
+
+   spi-flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s.dts 
b/arch/arm/dts/armada-xp-crs305-1g-4s.dts
new file mode 100644
index 00..1116f5c96c
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s.dts
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for CRS305-1G-4S board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Based on armada-xp-db.dts
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf100 (instead of the default
+ * 0xd000). The 0xf100 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx3236.dtsi"
+#include "armada-xp-crs305-1g-4s-u-boot.dtsi"
+
+/ {
+   model = "CRS305-1G-4S";
+   compatible = "marvell,armadaxp-98dx3236", "marvell,armadaxp-mv78260", 
"marvell,armadaxp", "marvell,armada-370-xp";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   bootargs = "console=ttyS0,115200 earlyprintk";
+   };
+
+   aliases {
+   spi0 = &spi0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x 0 0x2000>; /* 512 MB */
+   };
+};
+
+&L2 {
+   arm,parity-enable;
+   marvell,ecc-enable;
+};
+
+&devbus_bootcs {
+   status = "okay";
+
+   /* Device Bus parameters are required */
+
+   /* Read parameters */
+   devbus,bus-width= <16>;
+   devbus,turn-off-ps  = <6>;
+   devbus,badr-skew-ps = <0>;
+   devbus,acc-first-ps = <1

[U-Boot] [PATCH 0/1] Add MikroTik CRS305-1G-4S+IN board support

[Luka Kovacic]

I have commented out the code around MVEBU_GPIO1_BASE.

GPIO1 is a software reset button on the board, I might
use it later for resetting the board. 

GPIO0 is already working. It's currently used to turn
on an LED on board initialization.

Luka Kovacic (1):
  arm: mvebu: Add CRS305-1G-4S board

 arch/arm/dts/Makefile |   3 +-
 .../dts/armada-xp-crs305-1g-4s-u-boot.dtsi|  13 +++
 arch/arm/dts/armada-xp-crs305-1g-4s.dts   | 110 ++
 arch/arm/mach-mvebu/Kconfig   |   7 ++
 board/mikrotik/crs305-1g-4s/.gitignore|   1 +
 board/mikrotik/crs305-1g-4s/MAINTAINERS   |   7 ++
 board/mikrotik/crs305-1g-4s/Makefile  |  14 +++
 board/mikrotik/crs305-1g-4s/README|  23 
 board/mikrotik/crs305-1g-4s/binary.0  |  11 ++
 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c|  71 +++
 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in   |  12 ++
 configs/crs305-1g-4s_defconfig|  52 +
 include/configs/crs305-1g-4s.h|  37 ++
 13 files changed, 360 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s.dts
 create mode 100644 board/mikrotik/crs305-1g-4s/.gitignore
 create mode 100644 board/mikrotik/crs305-1g-4s/MAINTAINERS
 create mode 100644 board/mikrotik/crs305-1g-4s/Makefile
 create mode 100644 board/mikrotik/crs305-1g-4s/README
 create mode 100644 board/mikrotik/crs305-1g-4s/binary.0
 create mode 100644 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c
 create mode 100644 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in
 create mode 100644 configs/crs305-1g-4s_defconfig
 create mode 100644 include/configs/crs305-1g-4s.h

-- 
2.20.1

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

Re: [U-Boot] [PATCH 1/1] arm: mvebu: Add CRS305-1G-4S board

[Luka Kovačič]

On 2019-05-03 12:37, Chris Packham wrote:

On Fri, May 3, 2019 at 4:36 AM Luka Kovacic  wrote:


CRS305-1G-4S has a switch chip with an integrated CPU (98DX3236) and 
like some of the
other simillar boards requires bin_hdr. bin_hdr (DDR3 init stage) is 
currently retrieved

from the stock bootloader and compiled into the kwb image.

Adds support for U-Boot, enable UART, SPI, Winbond SPI flash chip 
support and writing env to SPI flash.


arch/arm/dts: Remove unused parameters in DTS for crs305-1g-4s

arch/arm/mach-mvebu: Set the proper processor for crs305-1g-4s 
(98DX3236)

---
 arch/arm/dts/Makefile |   3 +-
 .../dts/armada-xp-crs305-1g-4s-u-boot.dtsi|  13 +++
 arch/arm/dts/armada-xp-crs305-1g-4s.dts   | 110 
++

 arch/arm/mach-mvebu/Kconfig   |   7 ++
 board/mikrotik/crs305-1g-4s/.gitignore|   1 +
 board/mikrotik/crs305-1g-4s/MAINTAINERS   |   7 ++
 board/mikrotik/crs305-1g-4s/Makefile  |  14 +++
 board/mikrotik/crs305-1g-4s/README|  23 
 board/mikrotik/crs305-1g-4s/binary.0  |  11 ++
 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c|  68 +++
 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in   |  12 ++
 configs/crs305-1g-4s_defconfig|  51 
 include/configs/crs305-1g-4s.h|  37 ++
 13 files changed, 356 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s.dts
 create mode 100644 board/mikrotik/crs305-1g-4s/.gitignore
 create mode 100644 board/mikrotik/crs305-1g-4s/MAINTAINERS
 create mode 100644 board/mikrotik/crs305-1g-4s/Makefile
 create mode 100644 board/mikrotik/crs305-1g-4s/README
 create mode 100644 board/mikrotik/crs305-1g-4s/binary.0
 create mode 100644 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c
 create mode 100644 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in
 create mode 100644 configs/crs305-1g-4s_defconfig
 create mode 100644 include/configs/crs305-1g-4s.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02958..f463485149 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -161,7 +161,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-38x-controlcenterdc.dtb  \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb   \
-   armada-xp-db-xc3-24g4xg.dtb
+   armada-xp-db-xc3-24g4xg.dtb \
+   armada-xp-crs305-1g-4s.dtb

 dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \
uniphier-ld11-global.dtb \
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi 
b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi

new file mode 100644
index 00..8576a02730
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+&uart0 {
+   u-boot,dm-pre-reloc;
+};
+
+&spi0 {
+   u-boot,dm-pre-reloc;
+
+   spi-flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s.dts 
b/arch/arm/dts/armada-xp-crs305-1g-4s.dts

new file mode 100644
index 00..1116f5c96c
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s.dts
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for CRS305-1G-4S board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Based on armada-xp-db.dts
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped 
the

+ * internal registers to 0xf100 (instead of the default
+ * 0xd000). The 0xf100 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx3236.dtsi"
+#include "armada-xp-crs305-1g-4s-u-boot.dtsi"
+
+/ {
+   model = "CRS305-1G-4S";
+   compatible = "marvell,armadaxp-98dx3236", 
"marvell,armadaxp-mv78260", "marvell,armadaxp", 
"marvell,armada-370-xp";

+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   bootargs = "console=ttyS0,115200 earlyprintk";
+   };
+
+   aliases {
+   spi0 = &spi0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x 0 0x2000>; /* 512 MB */
+   };
+};
+
+&L2 {
+   arm,parity-enable;
+   marvell,ecc-enable;
+};
+
+&devbus_bootcs {
+   status = "okay";
+
+   /* Device Bus parameters are required */
+
+   /* Read parameters */
+   devbus,bus-width= <16>;
+   devbus,turn-off-ps  = <6>;
+   devbus,badr-skew-ps = <0>;
+   devbus,acc-first-ps = <124000>;
+   devbus,acc-next-ps  = <

Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)

[Julius Werner]

> Oh, ok. Guess I was just surprised that it says "can't extract compat"
> when it tries to check "comp"...

Well, what I'm trying to say in that error is "can't extract the
compatible string *because* the FDT is compressed", but without making
it three lines long.

> We should get a test together for this. There is an existing
> test_fit.py which might be expanded, or perhaps create a new one and
> share some code.

Oh, neat, I didn't know that exists there! Added a test case with
compressed images.

> > @@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> > const char *fit_uname_config;
> > const char *fit_base_uname_config;
> > const void *fit;
> > -   const void *buf;
> > +   void *buf;
> > +   void *loadbuf;
> > size_t size;
> > int type_ok, os_ok;
> > -   ulong load, data, len;
> > -   uint8_t os;
> > +   ulong load, load_end, data, len;
> > +   uint8_t os, comp;
> >  #ifndef USE_HOSTCC
> > uint8_t os_arch;
> >  #endif
> > @@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> > images->os.arch = os_arch;
> >  #endif
> >
> > -   if (image_type == IH_TYPE_FLATDT &&
> > -   !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
> > -   puts("FDT image is compressed");
> > -   return -EPROTONOSUPPORT;
> > -   }
> > -
> > bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
> > type_ok = fit_image_check_type(fit, noffset, image_type) ||
> >   fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
> > @@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> > bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
> >
> > /* get image data address and length */
> > -   if (fit_image_get_data_and_size(fit, noffset, &buf, &size)) {
> > +   if (fit_image_get_data_and_size(fit, noffset,
> > +   (const void **)&buf, &size)) {
> > printf("Could not find %s subimage data!\n", prop_name);
> > bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
> > return -ENOENT;
> > @@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> >
> >  #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
> > /* perform any post-processing on the image data */
> > -   board_fit_image_post_process((void **)&buf, &size);
> > +   board_fit_image_post_process(&buf, &size);
> >  #endif
> >
> > len = (ulong)size;
> >
> > -   /* verify that image data is a proper FDT blob */
> > -   if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
> > -   puts("Subimage data is not a FDT");
> > -   return -ENOEXEC;
> > -   }
> > -
> > bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
> >
> > -   /*
> > -* Work-around for eldk-4.2 which gives this warning if we try to
> > -* cast in the unmap_sysmem() call:
> > -* warning: initialization discards qualifiers from pointer target 
> > type
> > -*/
> > -   {
> > -   void *vbuf = (void *)buf;
> > -
> > -   data = map_to_sysmem(vbuf);
> > -   }
> > -
>
> We don't support gcc 4.2 now so this code can be simplified to the
> line you have below, but perhaps this should be in a separate patch?

Well, I just rearranged the whole thing by removing the const
qualifier from 'buf' itself, which I think makes this all way less
confusing. So this block should become obsolete regardless of compiler
version. That's somewhat intertwined with changing around all the load
address handling so I hope keeping it all in one patch is okay.

> > +   comp = IH_COMP_NONE;
> > +   loadbuf = buf;
> > +   /* Kernel images get decompressed later in bootm_host_load_image(). 
> > */
>
> But only for the host, right?

Oh, right, good catch, looked up the wrong function name. The normal
case goes through bootm_load_os().
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/2] fit: Support compat string property in configuration node

[Julius Werner]

This patch adds support for an optional optimization to compatible
string matching where the compatible string property from the root node
of the kernel FDT can be copied into the configuration node of the FIT
image. This is most useful when using compressed FDTs or when using FDT
overlays, where the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.

Signed-off-by: Julius Werner 
---
 common/image-fit.c | 67 +++---
 1 file changed, 39 insertions(+), 28 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 469c5c8f49..d32add6419 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1522,6 +1522,10 @@ int fit_check_format(const void *fit)
  * compatible list, "foo,bar", matches a compatible string in the root of fdt1.
  * "bim,bam" in fdt2 matches the second string which isn't as good as fdt1.
  *
+ * As an optimization, the compatible property from the FDT's root node can be
+ * copied into the configuration node in the FIT image. This is required to
+ * match configurations with compressed FDTs.
+ *
  * returns:
  * offset to the configuration to use if one was found
  * -1 otherwise
@@ -1554,55 +1558,62 @@ int fit_conf_find_compat(const void *fit, const void 
*fdt)
for (noffset = fdt_next_node(fit, confs_noffset, &ndepth);
(noffset >= 0) && (ndepth > 0);
noffset = fdt_next_node(fit, noffset, &ndepth)) {
-   const void *kfdt;
+   const void *fdt;
const char *kfdt_name;
-   int kfdt_noffset;
+   int kfdt_noffset, compat_noffset;
const char *cur_fdt_compat;
int len;
-   size_t size;
+   size_t sz;
int i;
 
if (ndepth > 1)
continue;
 
-   kfdt_name = fdt_getprop(fit, noffset, "fdt", &len);
-   if (!kfdt_name) {
-   debug("No fdt property found.\n");
-   continue;
-   }
-   kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
- kfdt_name);
-   if (kfdt_noffset < 0) {
-   debug("No image node named \"%s\" found.\n",
- kfdt_name);
-   continue;
-   }
+   /* If there's a compat property in the config node, use that. */
+   if (fdt_getprop(fit, noffset, "compatible", NULL)) {
+   fdt = fit;/* search in FIT image */
+   compat_noffset = noffset; /* search under config node */
+   } else {/* Otherwise extract it from the kernel FDT. */
+   kfdt_name = fdt_getprop(fit, noffset, "fdt", &len);
+   if (!kfdt_name) {
+   debug("No fdt property found.\n");
+   continue;
+   }
+   kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
+ kfdt_name);
+   if (kfdt_noffset < 0) {
+   debug("No image node named \"%s\" found.\n",
+ kfdt_name);
+   continue;
+   }
 
-   if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
-   debug("Can't extract compat from \"%s\" (compressed)\n",
- kfdt_name);
-   continue;
-   }
+   if (!fit_image_check_comp(fit, kfdt_noffset,
+ IH_COMP_NONE)) {
+   debug("Can't extract compat from \"%s\" "
+ "(compressed)\n", kfdt_name);
+   continue;
+   }
 
-   /*
-* Get a pointer to this configuration's fdt.
-*/
-   if (fit_image_get_data(fit, kfdt_noffset, &kfdt, &size)) {
-   debug("Failed to get fdt \"%s\".\n", kfdt_name);
-   continue;
+   /* search in this config's kernel FDT */
+   if (fit_image_get_data(fit, kfdt_noffset, &fdt, &sz)) {
+   debug("Failed to get fdt \"%s\".\n", kfdt_name);
+   continue;
+   }
+
+   compat_noffset = 0;  /* search kFDT under root node */
}
 
len = fdt_compat_len;
cur_fdt_compat = fdt_compat;
/*
 * Look for a match for each U-Boot compatibility string in
-* turn in this configuration'

[U-Boot] [PATCH v3 1/2] fit: Support compression for non-kernel components (e.g. FDT)

[Julius Werner]

This patch adds support for compressing non-kernel image nodes in a FIT
image (kernel nodes could already be compressed previously). This can
reduce the size of FIT images and therefore improve boot times
(especially when an image bundles many different kernel FDTs). The
images will automatically be decompressed on load.

This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.

Signed-off-by: Julius Werner 
---
 common/image-fit.c| 86 +++
 test/py/tests/test_fit.py | 29 +++--
 2 files changed, 77 insertions(+), 38 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index ac901e131c..469c5c8f49 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -22,6 +22,7 @@
 DECLARE_GLOBAL_DATA_PTR;
 #endif /* !USE_HOSTCC*/
 
+#include 
 #include 
 #include 
 #include 
@@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void 
*fdt)
  kfdt_name);
continue;
}
+
+   if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
+   debug("Can't extract compat from \"%s\" (compressed)\n",
+ kfdt_name);
+   continue;
+   }
+
/*
 * Get a pointer to this configuration's fdt.
 */
@@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
const char *fit_uname_config;
const char *fit_base_uname_config;
const void *fit;
-   const void *buf;
+   void *buf;
+   void *loadbuf;
size_t size;
int type_ok, os_ok;
-   ulong load, data, len;
-   uint8_t os;
+   ulong load, load_end, data, len;
+   uint8_t os, comp;
 #ifndef USE_HOSTCC
uint8_t os_arch;
 #endif
@@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
images->os.arch = os_arch;
 #endif
 
-   if (image_type == IH_TYPE_FLATDT &&
-   !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
-   puts("FDT image is compressed");
-   return -EPROTONOSUPPORT;
-   }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
type_ok = fit_image_check_type(fit, noffset, image_type) ||
  fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
@@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
 
/* get image data address and length */
-   if (fit_image_get_data_and_size(fit, noffset, &buf, &size)) {
+   if (fit_image_get_data_and_size(fit, noffset,
+   (const void **)&buf, &size)) {
printf("Could not find %s subimage data!\n", prop_name);
bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
return -ENOENT;
@@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 
 #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
/* perform any post-processing on the image data */
-   board_fit_image_post_process((void **)&buf, &size);
+   board_fit_image_post_process(&buf, &size);
 #endif
 
len = (ulong)size;
 
-   /* verify that image data is a proper FDT blob */
-   if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
-   puts("Subimage data is not a FDT");
-   return -ENOEXEC;
-   }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
 
-   /*
-* Work-around for eldk-4.2 which gives this warning if we try to
-* cast in the unmap_sysmem() call:
-* warning: initialization discards qualifiers from pointer target type
-*/
-   {
-   void *vbuf = (void *)buf;
-
-   data = map_to_sysmem(vbuf);
-   }
-
+   data = map_to_sysmem(buf);
+   load = data;
if (load_op == FIT_LOAD_IGNORED) {
/* Don't load */
} else if (fit_image_get_load(fit, noffset, &load)) {
@@ -1974,8 +1963,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
} else if (load_op != FIT_LOAD_OPTIONAL_NON_ZERO || load) {
ulong image_start, image_end;
-   ulong load_end;
-   void *dst;
 
/*
 * move image data to the load address,
@@ -1993,14 +1980,45 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 
printf("   Loading %s from 0x%08lx to 0x%08lx\n",
   prop_name, data, load);
+   } else {
+   load = data;/* No load address specified */
+   }
+
+   comp = IH_COMP_NONE;
+   loadbu

[U-Boot] [PATCH v3 0/2] fit: Image node compression

[Julius Werner]

This patch series adds compression support for non-kernel FIT image
nodes (e.g. FDTs). The first patch adds the compression support
itself, the second adds a new feature to compatible string matching
that allows it to be useful with compressed FDTs.

Sandbox-tested with FIT images with and without compressed FDTs, with
and without overlays, in both compatible string matching and direct
config selection modes. Also expanded the test_fit pytest to include a
case with compressed kernel, FDT and ramdisk.

Julius Werner (2):
  fit: Support compression for non-kernel components (e.g. FDT)
- Changes for v2:
  - Changed from only supporting compressed FDTs to supporting all
non-kernel image node types.
  fit: Support compat string property in configuration node

 common/image-fit.c | 140 +++--
 1 file changed, 83 insertions(+), 57 deletions(-)

-- 
2.20.1

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

Re: [U-Boot] [PATCH 2/2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode

[Trent Piepho]

On Thu, 2019-05-02 at 07:23 +0200, Heiko Schocher wrote:
> Am 30.04.2019 um 18:04 schrieb Trent Piepho:
> > On Tue, 2019-04-30 at 06:34 +0200, Heiko Schocher wrote:
> > > Am 16.04.2019 um 00:02 schrieb Trent Piepho:
> > > > This is an old driver that supports both device mapped and non-mapped
> > > > mode, and covers a wide range of hardware.  It's hard to change without
> > > > risking breaking something.  I have to tried to be exceedingly detailed
> > > > in this patch, so please excuse the length of the commit essay that
> > > > follows.
> > > > 
> > > 
> > 
> > The patches should be automatically fixed by git am, as it will strip
> > DOS endings by default.
> 
> Unfortunately, your v2 version has the same problem :-(
> 
> Can you please check, if your patches are OK?

They look correct, thanks for applying them.

I'm not sure where the mangling is happening.  I assure you the patches
 I'm sending are correct.  They arrive at both my work and gmail
account unmangled.  Yet somehow the patchwork mbox file has DOS line
endings added to the diff portion but not the commit message.  I wonder
if the flaw is somewhere in in the denx list server or in patchwork?

Of course, if no one else's patches get mangled, it's probably
something about microsoft's email server that is the problem.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd: reset: add parameters to specify reboot_mode

[Simon Glass]

Hi Simon,

On Fri, 3 May 2019 at 14:43, Marek Vasut  wrote:
>
> On 5/3/19 10:40 PM, Simon Goldschmidt wrote:
> >
> >
> > On 03.05.19 22:37, Marek Vasut wrote:
> >> On 5/3/19 10:33 PM, Simon Goldschmidt wrote:
> >>>
> >>>
> >>> On 03.05.19 22:27, Marek Vasut wrote:
>  On 5/3/19 10:25 PM, Simon Goldschmidt wrote:
> > This patch adds parameter support for the 'reset' command to specify
> > the reboot mode (cold vs. warm).
> >
> > Checking these parameters is implemented in the DM implementation.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> >cmd/boot.c |  4 ++--
> >drivers/sysreset/sysreset-uclass.c | 17 -
> >2 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/cmd/boot.c b/cmd/boot.c
> > index 9150fce80b..c3f33a9ca3 100644
> > --- a/cmd/boot.c
> > +++ b/cmd/boot.c
> > @@ -56,9 +56,9 @@ U_BOOT_CMD(
> >#endif
> >  U_BOOT_CMD(
> > -reset, 1, 0,do_reset,
> > +reset, 2, 0,do_reset,
> >"Perform RESET of the CPU",
> > -""
> > +"[] - type of reboot"
> >);
> >  #ifdef CONFIG_CMD_POWEROFF
> > diff --git a/drivers/sysreset/sysreset-uclass.c
> > b/drivers/sysreset/sysreset-uclass.c
> > index ad831c703a..fbda3f44f2 100644
> > --- a/drivers/sysreset/sysreset-uclass.c
> > +++ b/drivers/sysreset/sysreset-uclass.c
> > @@ -111,9 +111,24 @@ void reset_cpu(ulong addr)
> >  int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> > argv[])
> >{
> > +enum sysreset_t reboot_mode = SYSRESET_COLD;
> > +
> > +if (argc > 1 && argv[1]) {
> > +switch (*argv[1]) {
> > +case 'w':
> > +reboot_mode = SYSRESET_WARM;
> > +printf("warm ");
> > +break;
> > +case 'c':
> > +reboot_mode = SYSRESET_COLD;
> > +printf("cold ");
> > +break;

Please can we have a pytest for this command?

Regards,
Simon

> 
>  This looks like a platform or driver specific stuff ?
> >>>
> >>> Ouch, I just saw the extra printf might have to be removed in a v2...
> >>>
> >>> Anyway, except for that, I don't think it's platform or driver specific.
> >>> It's just a way to make the cmd 'reset' take arguments that map to enum
> >>> sysreset_t.
> >>
> >> Cold vs. Warm reset is socfpga specific. The reset driver should
> >> probably somehow register supported reset modes (warm/cold) with the
> >> reset core code.
> >
> > But it's a thing the UCLASS_SYSRESET already exposes. I haven't added
> > the enum values for that, I merely exposed them to the cmd "API". I
> > can't see anything socfpga specific about it.
>
> Ah, then socfpga just maps to that "API" very well, nice. I wasn't aware
> of it.
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Simon Goldschmidt]

Marek Vasut  schrieb am Fr., 3. Mai 2019, 22:42:

> On 5/3/19 10:39 PM, Simon Goldschmidt wrote:
> >
> >
> > On 03.05.19 22:35, Marek Vasut wrote:
> >> On 5/3/19 10:30 PM, Simon Goldschmidt wrote:
> >>>
> >>>
> >>> On 03.05.19 22:28, Marek Vasut wrote:
>  On 5/3/19 10:08 PM, Simon Goldschmidt wrote:
> > This moves the code that enables the Boot ROM to just jump to SRAM
> > instead
> > of loading SPL from the original boot source on warm reboot.
> >
> > Instead of always enabling this, an environment callback for the
> > env var
> > "socfpga_reboot_from_sram" is used. This way, the behaviour can be
> > enabled
> > at runtime and via saved environment.
> >
> > Signed-off-by: Simon Goldschmidt 
> 
>  Would that be like a default "reset" command action ?
>  This probably shouldn't be socfpga specific then.
> >>>
> >>> No, it's a thing that lives on and influences even the soft reset
> issued
> >>> by linux "reboot" command. This is something *very* socfpga specific.
> >>
> >> Hmmm, so isn't this a policy to be configured on the Linux end ?
> >
> > Might be, but it affects U-Boot's 'reset' command as well. And I guess
> > it's set up in U-Boot this early to ensure it always works.
>
> Drat, that's right. So there has to be some way to agree on how the
> reset works between the kernel and U-Boot ?
>
> > If it were for me, we could drop writing this magic altogether. I just
> > figured some boards might require it to be written somewhere, and came
> > up with a patch that might save those boards with the way it was before.
>
> Isn't this magic actually used by bootrom ?
>

Right. It tells the boot rom to jump to ocram on next reboot instead of
loading spl from qspi or mmc. But if that's required or not a good idea at
all depends on many factors. Some of them board related, some U-Boot
related and some Linux related (depending on the hardware and drivers used).

Regards,
Simon

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

Re: [U-Boot] [PATCH] cmd: reset: add parameters to specify reboot_mode

[Marek Vasut]

On 5/3/19 10:40 PM, Simon Goldschmidt wrote:
> 
> 
> On 03.05.19 22:37, Marek Vasut wrote:
>> On 5/3/19 10:33 PM, Simon Goldschmidt wrote:
>>>
>>>
>>> On 03.05.19 22:27, Marek Vasut wrote:
 On 5/3/19 10:25 PM, Simon Goldschmidt wrote:
> This patch adds parameter support for the 'reset' command to specify
> the reboot mode (cold vs. warm).
>
> Checking these parameters is implemented in the DM implementation.
>
> Signed-off-by: Simon Goldschmidt 
> ---
>
>    cmd/boot.c |  4 ++--
>    drivers/sysreset/sysreset-uclass.c | 17 -
>    2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/boot.c b/cmd/boot.c
> index 9150fce80b..c3f33a9ca3 100644
> --- a/cmd/boot.c
> +++ b/cmd/boot.c
> @@ -56,9 +56,9 @@ U_BOOT_CMD(
>    #endif
>      U_BOOT_CMD(
> -    reset, 1, 0,    do_reset,
> +    reset, 2, 0,    do_reset,
>    "Perform RESET of the CPU",
> -    ""
> +    "[] - type of reboot"
>    );
>      #ifdef CONFIG_CMD_POWEROFF
> diff --git a/drivers/sysreset/sysreset-uclass.c
> b/drivers/sysreset/sysreset-uclass.c
> index ad831c703a..fbda3f44f2 100644
> --- a/drivers/sysreset/sysreset-uclass.c
> +++ b/drivers/sysreset/sysreset-uclass.c
> @@ -111,9 +111,24 @@ void reset_cpu(ulong addr)
>      int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])
>    {
> +    enum sysreset_t reboot_mode = SYSRESET_COLD;
> +
> +    if (argc > 1 && argv[1]) {
> +    switch (*argv[1]) {
> +    case 'w':
> +    reboot_mode = SYSRESET_WARM;
> +    printf("warm ");
> +    break;
> +    case 'c':
> +    reboot_mode = SYSRESET_COLD;
> +    printf("cold ");
> +    break;

 This looks like a platform or driver specific stuff ?
>>>
>>> Ouch, I just saw the extra printf might have to be removed in a v2...
>>>
>>> Anyway, except for that, I don't think it's platform or driver specific.
>>> It's just a way to make the cmd 'reset' take arguments that map to enum
>>> sysreset_t.
>>
>> Cold vs. Warm reset is socfpga specific. The reset driver should
>> probably somehow register supported reset modes (warm/cold) with the
>> reset core code.
> 
> But it's a thing the UCLASS_SYSRESET already exposes. I haven't added
> the enum values for that, I merely exposed them to the cmd "API". I
> can't see anything socfpga specific about it.

Ah, then socfpga just maps to that "API" very well, nice. I wasn't aware
of it.

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

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Marek Vasut]

On 5/3/19 10:39 PM, Simon Goldschmidt wrote:
> 
> 
> On 03.05.19 22:35, Marek Vasut wrote:
>> On 5/3/19 10:30 PM, Simon Goldschmidt wrote:
>>>
>>>
>>> On 03.05.19 22:28, Marek Vasut wrote:
 On 5/3/19 10:08 PM, Simon Goldschmidt wrote:
> This moves the code that enables the Boot ROM to just jump to SRAM
> instead
> of loading SPL from the original boot source on warm reboot.
>
> Instead of always enabling this, an environment callback for the
> env var
> "socfpga_reboot_from_sram" is used. This way, the behaviour can be
> enabled
> at runtime and via saved environment.
>
> Signed-off-by: Simon Goldschmidt 

 Would that be like a default "reset" command action ?
 This probably shouldn't be socfpga specific then.
>>>
>>> No, it's a thing that lives on and influences even the soft reset issued
>>> by linux "reboot" command. This is something *very* socfpga specific.
>>
>> Hmmm, so isn't this a policy to be configured on the Linux end ?
> 
> Might be, but it affects U-Boot's 'reset' command as well. And I guess
> it's set up in U-Boot this early to ensure it always works.

Drat, that's right. So there has to be some way to agree on how the
reset works between the kernel and U-Boot ?

> If it were for me, we could drop writing this magic altogether. I just
> figured some boards might require it to be written somewhere, and came
> up with a patch that might save those boards with the way it was before.

Isn't this magic actually used by bootrom ?

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

Re: [U-Boot] [PATCH] cmd: reset: add parameters to specify reboot_mode

[Simon Goldschmidt]

On 03.05.19 22:37, Marek Vasut wrote:

On 5/3/19 10:33 PM, Simon Goldschmidt wrote:



On 03.05.19 22:27, Marek Vasut wrote:

On 5/3/19 10:25 PM, Simon Goldschmidt wrote:

This patch adds parameter support for the 'reset' command to specify
the reboot mode (cold vs. warm).

Checking these parameters is implemented in the DM implementation.

Signed-off-by: Simon Goldschmidt 
---

   cmd/boot.c |  4 ++--
   drivers/sysreset/sysreset-uclass.c | 17 -
   2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/cmd/boot.c b/cmd/boot.c
index 9150fce80b..c3f33a9ca3 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -56,9 +56,9 @@ U_BOOT_CMD(
   #endif
     U_BOOT_CMD(
-    reset, 1, 0,    do_reset,
+    reset, 2, 0,    do_reset,
   "Perform RESET of the CPU",
-    ""
+    "[] - type of reboot"
   );
     #ifdef CONFIG_CMD_POWEROFF
diff --git a/drivers/sysreset/sysreset-uclass.c
b/drivers/sysreset/sysreset-uclass.c
index ad831c703a..fbda3f44f2 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -111,9 +111,24 @@ void reset_cpu(ulong addr)
     int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
   {
+    enum sysreset_t reboot_mode = SYSRESET_COLD;
+
+    if (argc > 1 && argv[1]) {
+    switch (*argv[1]) {
+    case 'w':
+    reboot_mode = SYSRESET_WARM;
+    printf("warm ");
+    break;
+    case 'c':
+    reboot_mode = SYSRESET_COLD;
+    printf("cold ");
+    break;


This looks like a platform or driver specific stuff ?


Ouch, I just saw the extra printf might have to be removed in a v2...

Anyway, except for that, I don't think it's platform or driver specific.
It's just a way to make the cmd 'reset' take arguments that map to enum
sysreset_t.


Cold vs. Warm reset is socfpga specific. The reset driver should
probably somehow register supported reset modes (warm/cold) with the
reset core code.


But it's a thing the UCLASS_SYSRESET already exposes. I haven't added 
the enum values for that, I merely exposed them to the cmd "API". I 
can't see anything socfpga specific about it.





There is a problem in that other platforms without UCLASS_SYSRESET don't
handle these arguments, but I thought UCLASS_SYSRESET would be the
future, and the rest would be "legacy"?


Yep.


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

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Simon Goldschmidt]

On 03.05.19 22:35, Marek Vasut wrote:

On 5/3/19 10:30 PM, Simon Goldschmidt wrote:



On 03.05.19 22:28, Marek Vasut wrote:

On 5/3/19 10:08 PM, Simon Goldschmidt wrote:

This moves the code that enables the Boot ROM to just jump to SRAM
instead
of loading SPL from the original boot source on warm reboot.

Instead of always enabling this, an environment callback for the env var
"socfpga_reboot_from_sram" is used. This way, the behaviour can be
enabled
at runtime and via saved environment.

Signed-off-by: Simon Goldschmidt 


Would that be like a default "reset" command action ?
This probably shouldn't be socfpga specific then.


No, it's a thing that lives on and influences even the soft reset issued
by linux "reboot" command. This is something *very* socfpga specific.


Hmmm, so isn't this a policy to be configured on the Linux end ?


Might be, but it affects U-Boot's 'reset' command as well. And I guess 
it's set up in U-Boot this early to ensure it always works.


If it were for me, we could drop writing this magic altogether. I just 
figured some boards might require it to be written somewhere, and came 
up with a patch that might save those boards with the way it was before.


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

Re: [U-Boot] [PATCH] sysreset: add support for socfpga sysreset

[Marek Vasut]

On 5/3/19 10:37 PM, Simon Goldschmidt wrote:
> 
> 
> On 03.05.19 22:27, Marek Vasut wrote:
>> On 5/3/19 10:21 PM, Simon Goldschmidt wrote:
>>> This moves sysreset support for socfgpa from ad-hoc code in mach-socfpga
>>> to a UCLASS_SYSRESET based dm driver.
>>>
>>> A side effect is that gen5 and a10 can now differ between cold and warm
>>> reset.
>>
>> s/differ/select/ ?
> 
> Right.
> 
>>
>>> Signed-off-by: Simon Goldschmidt 
>>> ---
>>>
>>>   arch/arm/Kconfig  |  3 +
>>>   arch/arm/mach-socfpga/Makefile    |  1 -
>>>   .../mach-socfpga/include/mach/reset_manager.h |  1 +
>>>   arch/arm/mach-socfpga/reset_manager.c | 41 -
>>>   drivers/sysreset/Kconfig  |  6 ++
>>>   drivers/sysreset/Makefile |  1 +
>>>   drivers/sysreset/sysreset_socfpga.c   | 58 +++
>>>   7 files changed, 69 insertions(+), 42 deletions(-)
>>>   delete mode 100644 arch/arm/mach-socfpga/reset_manager.c
>>>   create mode 100644 drivers/sysreset/sysreset_socfpga.c
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 49f01f1ff1..656ff92bd8 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -823,6 +823,7 @@ config ARCH_SOCFPGA
>>>   select OF_CONTROL
>>>   select SPL_DM_RESET if DM_RESET
>>>   select SPL_DM_SERIAL
>>> +    select SPL_DRIVERS_MISC_SUPPORT
>>
>> Why MISC ?
> 
> Because that's what includes the sysreset drivers into SPL.

That seems wrong ?

>>>   select SPL_LIBCOMMON_SUPPORT
>>>   select SPL_LIBGENERIC_SUPPORT
>>>   select SPL_NAND_SUPPORT if SPL_NAND_DENALI
>>> @@ -833,6 +834,8 @@ config ARCH_SOCFPGA
>>>   select SUPPORT_SPL
>>>   select SYS_NS16550
>>>   select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 ||
>>> TARGET_SOCFPGA_ARRIA10
>>> +    select SYSRESET
>>> +    select SYSRESET_SOCFPGA
>>>   imply CMD_DM
>>>   imply CMD_MTDPARTS
>>>   imply CRC32_VERIFY
>>> diff --git a/arch/arm/mach-socfpga/Makefile
>>> b/arch/arm/mach-socfpga/Makefile
>>> index e66720447f..fc1181cb27 100644
>>> --- a/arch/arm/mach-socfpga/Makefile
>>> +++ b/arch/arm/mach-socfpga/Makefile
>>> @@ -8,7 +8,6 @@
>>>   obj-y    += board.o
>>>   obj-y    += clock_manager.o
>>>   obj-y    += misc.o
>>> -obj-y    += reset_manager.o
>>>     ifdef CONFIG_TARGET_SOCFPGA_GEN5
>>>   obj-y    += clock_manager_gen5.o
>>> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> index 42beaecdd6..6ad037e325 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> @@ -11,6 +11,7 @@ void reset_cpu(ulong addr);
>>>   void socfpga_per_reset(u32 reset, int set);
>>>   void socfpga_per_reset_all(void);
>>>   +#define RSTMGR_CTRL_SWCOLDRSTREQ_LSB 0
>>
>> Separate patch
> 
> Fair enough.
> 
>>
>>>   #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1
>>>     /*
>>> diff --git a/arch/arm/mach-socfpga/reset_manager.c
>>> b/arch/arm/mach-socfpga/reset_manager.c
>>> deleted file mode 100644
>>> index e0a01ed07a..00
>>> --- a/arch/arm/mach-socfpga/reset_manager.c
>>> +++ /dev/null
>>> @@ -1,41 +0,0 @@
>>> -// SPDX-License-Identifier: GPL-2.0+
>>> -/*
>>> - *  Copyright (C) 2013 Altera Corporation 
>>> - */
>>> -
>>> -
>>> -#include 
>>> -#include 
>>> -#include 
>>> -
>>> -#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
>>> -#include 
>>> -#endif
>>> -
>>> -DECLARE_GLOBAL_DATA_PTR;
>>> -
>>> -#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
>>> -static const struct socfpga_reset_manager *reset_manager_base =
>>> -    (void *)SOCFPGA_RSTMGR_ADDRESS;
>>> -#endif
>>> -
>>> -/*
>>> - * Write the reset manager register to cause reset
>>> - */
>>> -void reset_cpu(ulong addr)
>>> -{
>>> -    /* request a warm reset */
>>> -#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
>>> -    puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>> -    mbox_reset_cold();
>>> -#else
>>> -    writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
>>> -   &reset_manager_base->ctrl);
>>> -#endif
>>> -    /*
>>> - * infinite loop here as watchdog will trigger and reset
>>> - * the processor
>>> - */
>>> -    while (1)
>>> -    ;
>>> -}
>>> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
>>> index 8ce3e2e207..8b6e6626d2 100644
>>> --- a/drivers/sysreset/Kconfig
>>> +++ b/drivers/sysreset/Kconfig
>>> @@ -36,6 +36,12 @@ config SYSRESET_PSCI
>>>     Enable PSCI SYSTEM_RESET function call.  To use this, PSCI
>>> firmware
>>>     must be running on your system.
>>>   +config SYSRESET_SOCFPGA
>>> +    bool "Enable support for Intel SOCFPGA family"
>>> +    depends on ARCH_SOCFPGA
>>> +    help
>>> +  This enables the system reset driver support for Intel SOCFPGA
>>> SoCs.
>>> +
>>>   config SYSRESET_TI_SCI
>>>   bool "TI System Control Interface (TI SCI) system reset driver"
>>>   depends on TI_SCI_PROTOCOL
>>> diff --git a/drivers/sysreset/Mak

Re: [U-Boot] [PATCH] cmd: reset: add parameters to specify reboot_mode

[Marek Vasut]

On 5/3/19 10:33 PM, Simon Goldschmidt wrote:
> 
> 
> On 03.05.19 22:27, Marek Vasut wrote:
>> On 5/3/19 10:25 PM, Simon Goldschmidt wrote:
>>> This patch adds parameter support for the 'reset' command to specify
>>> the reboot mode (cold vs. warm).
>>>
>>> Checking these parameters is implemented in the DM implementation.
>>>
>>> Signed-off-by: Simon Goldschmidt 
>>> ---
>>>
>>>   cmd/boot.c |  4 ++--
>>>   drivers/sysreset/sysreset-uclass.c | 17 -
>>>   2 files changed, 18 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/cmd/boot.c b/cmd/boot.c
>>> index 9150fce80b..c3f33a9ca3 100644
>>> --- a/cmd/boot.c
>>> +++ b/cmd/boot.c
>>> @@ -56,9 +56,9 @@ U_BOOT_CMD(
>>>   #endif
>>>     U_BOOT_CMD(
>>> -    reset, 1, 0,    do_reset,
>>> +    reset, 2, 0,    do_reset,
>>>   "Perform RESET of the CPU",
>>> -    ""
>>> +    "[] - type of reboot"
>>>   );
>>>     #ifdef CONFIG_CMD_POWEROFF
>>> diff --git a/drivers/sysreset/sysreset-uclass.c
>>> b/drivers/sysreset/sysreset-uclass.c
>>> index ad831c703a..fbda3f44f2 100644
>>> --- a/drivers/sysreset/sysreset-uclass.c
>>> +++ b/drivers/sysreset/sysreset-uclass.c
>>> @@ -111,9 +111,24 @@ void reset_cpu(ulong addr)
>>>     int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
>>> argv[])
>>>   {
>>> +    enum sysreset_t reboot_mode = SYSRESET_COLD;
>>> +
>>> +    if (argc > 1 && argv[1]) {
>>> +    switch (*argv[1]) {
>>> +    case 'w':
>>> +    reboot_mode = SYSRESET_WARM;
>>> +    printf("warm ");
>>> +    break;
>>> +    case 'c':
>>> +    reboot_mode = SYSRESET_COLD;
>>> +    printf("cold ");
>>> +    break;
>>
>> This looks like a platform or driver specific stuff ?
> 
> Ouch, I just saw the extra printf might have to be removed in a v2...
> 
> Anyway, except for that, I don't think it's platform or driver specific.
> It's just a way to make the cmd 'reset' take arguments that map to enum
> sysreset_t.

Cold vs. Warm reset is socfpga specific. The reset driver should
probably somehow register supported reset modes (warm/cold) with the
reset core code.

> There is a problem in that other platforms without UCLASS_SYSRESET don't
> handle these arguments, but I thought UCLASS_SYSRESET would be the
> future, and the rest would be "legacy"?

Yep.

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

Re: [U-Boot] [PATCH] sysreset: add support for socfpga sysreset

[Simon Goldschmidt]

On 03.05.19 22:27, Marek Vasut wrote:

On 5/3/19 10:21 PM, Simon Goldschmidt wrote:

This moves sysreset support for socfgpa from ad-hoc code in mach-socfpga
to a UCLASS_SYSRESET based dm driver.

A side effect is that gen5 and a10 can now differ between cold and warm
reset.


s/differ/select/ ?


Right.




Signed-off-by: Simon Goldschmidt 
---

  arch/arm/Kconfig  |  3 +
  arch/arm/mach-socfpga/Makefile|  1 -
  .../mach-socfpga/include/mach/reset_manager.h |  1 +
  arch/arm/mach-socfpga/reset_manager.c | 41 -
  drivers/sysreset/Kconfig  |  6 ++
  drivers/sysreset/Makefile |  1 +
  drivers/sysreset/sysreset_socfpga.c   | 58 +++
  7 files changed, 69 insertions(+), 42 deletions(-)
  delete mode 100644 arch/arm/mach-socfpga/reset_manager.c
  create mode 100644 drivers/sysreset/sysreset_socfpga.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49f01f1ff1..656ff92bd8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -823,6 +823,7 @@ config ARCH_SOCFPGA
select OF_CONTROL
select SPL_DM_RESET if DM_RESET
select SPL_DM_SERIAL
+   select SPL_DRIVERS_MISC_SUPPORT


Why MISC ?


Because that's what includes the sysreset drivers into SPL.




select SPL_LIBCOMMON_SUPPORT
select SPL_LIBGENERIC_SUPPORT
select SPL_NAND_SUPPORT if SPL_NAND_DENALI
@@ -833,6 +834,8 @@ config ARCH_SOCFPGA
select SUPPORT_SPL
select SYS_NS16550
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+   select SYSRESET
+   select SYSRESET_SOCFPGA
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e66720447f..fc1181cb27 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -8,7 +8,6 @@
  obj-y += board.o
  obj-y += clock_manager.o
  obj-y += misc.o
-obj-y  += reset_manager.o
  
  ifdef CONFIG_TARGET_SOCFPGA_GEN5

  obj-y += clock_manager_gen5.o
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 42beaecdd6..6ad037e325 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -11,6 +11,7 @@ void reset_cpu(ulong addr);
  void socfpga_per_reset(u32 reset, int set);
  void socfpga_per_reset_all(void);
  
+#define RSTMGR_CTRL_SWCOLDRSTREQ_LSB 0


Separate patch


Fair enough.




  #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1
  
  /*

diff --git a/arch/arm/mach-socfpga/reset_manager.c 
b/arch/arm/mach-socfpga/reset_manager.c
deleted file mode 100644
index e0a01ed07a..00
--- a/arch/arm/mach-socfpga/reset_manager.c
+++ /dev/null
@@ -1,41 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- *  Copyright (C) 2013 Altera Corporation 
- */
-
-
-#include 
-#include 
-#include 
-
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-#include 
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-static const struct socfpga_reset_manager *reset_manager_base =
-   (void *)SOCFPGA_RSTMGR_ADDRESS;
-#endif
-
-/*
- * Write the reset manager register to cause reset
- */
-void reset_cpu(ulong addr)
-{
-   /* request a warm reset */
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-   puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
-   mbox_reset_cold();
-#else
-   writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
-  &reset_manager_base->ctrl);
-#endif
-   /*
-* infinite loop here as watchdog will trigger and reset
-* the processor
-*/
-   while (1)
-   ;
-}
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..8b6e6626d2 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -36,6 +36,12 @@ config SYSRESET_PSCI
  Enable PSCI SYSTEM_RESET function call.  To use this, PSCI firmware
  must be running on your system.
  
+config SYSRESET_SOCFPGA

+   bool "Enable support for Intel SOCFPGA family"
+   depends on ARCH_SOCFPGA
+   help
+ This enables the system reset driver support for Intel SOCFPGA SoCs.
+
  config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index b3728ac17f..0241b0132d 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
  obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
  obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
  obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
  obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
  obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Marek Vasut]

On 5/3/19 10:30 PM, Simon Goldschmidt wrote:
> 
> 
> On 03.05.19 22:28, Marek Vasut wrote:
>> On 5/3/19 10:08 PM, Simon Goldschmidt wrote:
>>> This moves the code that enables the Boot ROM to just jump to SRAM
>>> instead
>>> of loading SPL from the original boot source on warm reboot.
>>>
>>> Instead of always enabling this, an environment callback for the env var
>>> "socfpga_reboot_from_sram" is used. This way, the behaviour can be
>>> enabled
>>> at runtime and via saved environment.
>>>
>>> Signed-off-by: Simon Goldschmidt 
>>
>> Would that be like a default "reset" command action ?
>> This probably shouldn't be socfpga specific then.
> 
> No, it's a thing that lives on and influences even the soft reset issued
> by linux "reboot" command. This is something *very* socfpga specific.

Hmmm, so isn't this a policy to be configured on the Linux end ?

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

Re: [U-Boot] [PATCH] cmd: reset: add parameters to specify reboot_mode

[Simon Goldschmidt]

On 03.05.19 22:27, Marek Vasut wrote:

On 5/3/19 10:25 PM, Simon Goldschmidt wrote:

This patch adds parameter support for the 'reset' command to specify
the reboot mode (cold vs. warm).

Checking these parameters is implemented in the DM implementation.

Signed-off-by: Simon Goldschmidt 
---

  cmd/boot.c |  4 ++--
  drivers/sysreset/sysreset-uclass.c | 17 -
  2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/cmd/boot.c b/cmd/boot.c
index 9150fce80b..c3f33a9ca3 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -56,9 +56,9 @@ U_BOOT_CMD(
  #endif
  
  U_BOOT_CMD(

-   reset, 1, 0,do_reset,
+   reset, 2, 0,do_reset,
"Perform RESET of the CPU",
-   ""
+   "[] - type of reboot"
  );
  
  #ifdef CONFIG_CMD_POWEROFF

diff --git a/drivers/sysreset/sysreset-uclass.c 
b/drivers/sysreset/sysreset-uclass.c
index ad831c703a..fbda3f44f2 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -111,9 +111,24 @@ void reset_cpu(ulong addr)
  
  int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

  {
+   enum sysreset_t reboot_mode = SYSRESET_COLD;
+
+   if (argc > 1 && argv[1]) {
+   switch (*argv[1]) {
+   case 'w':
+   reboot_mode = SYSRESET_WARM;
+   printf("warm ");
+   break;
+   case 'c':
+   reboot_mode = SYSRESET_COLD;
+   printf("cold ");
+   break;


This looks like a platform or driver specific stuff ?


Ouch, I just saw the extra printf might have to be removed in a v2...

Anyway, except for that, I don't think it's platform or driver specific. 
It's just a way to make the cmd 'reset' take arguments that map to enum 
sysreset_t.


There is a problem in that other platforms without UCLASS_SYSRESET don't 
handle these arguments, but I thought UCLASS_SYSRESET would be the 
future, and the rest would be "legacy"?


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

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Simon Goldschmidt]

On 03.05.19 22:28, Marek Vasut wrote:

On 5/3/19 10:08 PM, Simon Goldschmidt wrote:

This moves the code that enables the Boot ROM to just jump to SRAM instead
of loading SPL from the original boot source on warm reboot.

Instead of always enabling this, an environment callback for the env var
"socfpga_reboot_from_sram" is used. This way, the behaviour can be enabled
at runtime and via saved environment.

Signed-off-by: Simon Goldschmidt 


Would that be like a default "reset" command action ?
This probably shouldn't be socfpga specific then.


No, it's a thing that lives on and influences even the soft reset issued 
by linux "reboot" command. This is something *very* socfpga specific.


Regards,
Simon




---

  arch/arm/mach-socfpga/misc_gen5.c | 49 +--
  include/configs/socfpga_common.h  |  5 
  2 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
b/arch/arm/mach-socfpga/misc_gen5.c
index 9865f5b5b1..db662bb22a 100644
--- a/arch/arm/mach-socfpga/misc_gen5.c
+++ b/arch/arm/mach-socfpga/misc_gen5.c
@@ -6,6 +6,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -182,15 +183,6 @@ int arch_early_init_r(void)
  {
int i;
  
-	/*

-* Write magic value into magic register to unlock support for
-* issuing warm reset. The ancient kernel code expects this
-* value to be written into the register by the bootloader, so
-* to support that old code, we write it here instead of in the
-* reset_cpu() function just before resetting the CPU.
-*/
-   writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
-
for (i = 0; i < 8; i++)  /* Cache initial SW setting regs */
iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);
  
@@ -255,4 +247,43 @@ void do_bridge_reset(int enable)

writel(1, &nic301_regs->remap);
}
  }
+
+/*
+ * This function controls the reboot behaviour via an environment callback to
+ * the variable "socfpga_reboot_from_sram".
+ *
+ * Setting this variable to 1 writes a magic value into a magic register that
+ * makes the Boot ROM jump to SRAM on a warm reset. Note that this doesn't
+ * happen on cold reset, and that the SPL is not CRC protected, so if it gets
+ * overwritten before boot, something bad will happen.
+ *
+ * Given these limitations, this env callback only exists for backwards
+ * compatibility.
+ */
+static int on_socfpga_reboot_from_sram(const char *name, const char *value,
+  enum env_op op, int flags)
+{
+   int val;
+   u32 reg;
+
+   val = simple_strtoul(value, NULL, 10);
+   if (val) {
+   /*
+* Write magic value into magic register to unlock support for
+* issuing warm reset. The ancient kernel code expects this
+* value to be written into the register by the bootloader, so
+* to support that old code, we write it here instead of in the
+* reset_cpu() function just before resetting the CPU.
+*/
+   reg = 0xae9efebc;
+   } else {
+   reg = 0;
+   }
+   writel(reg, &sysmgr_regs->romcodegrp_warmramgrp_enable);
+
+   return 0;
+}
+
+U_BOOT_ENV_CALLBACK(socfpga_reboot_from_sram, on_socfpga_reboot_from_sram);
+
  #endif
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index d1034ac280..aae4daf5d2 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -273,4 +273,9 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
  #endif
  #endif
  
+#ifndef CONFIG_ENV_CALLBACK_LIST_STATIC

+#define CONFIG_ENV_CALLBACK_LIST_STATIC \
+   "socfpga_reboot_from_sram:socfpga_reboot_from_sram"
+#endif
+
  #endif/* __CONFIG_SOCFPGA_COMMON_H__ */





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

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Marek Vasut]

On 5/3/19 10:08 PM, Simon Goldschmidt wrote:
> This moves the code that enables the Boot ROM to just jump to SRAM instead
> of loading SPL from the original boot source on warm reboot.
> 
> Instead of always enabling this, an environment callback for the env var
> "socfpga_reboot_from_sram" is used. This way, the behaviour can be enabled
> at runtime and via saved environment.
> 
> Signed-off-by: Simon Goldschmidt 

Would that be like a default "reset" command action ?
This probably shouldn't be socfpga specific then.

> ---
> 
>  arch/arm/mach-socfpga/misc_gen5.c | 49 +--
>  include/configs/socfpga_common.h  |  5 
>  2 files changed, 45 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
> b/arch/arm/mach-socfpga/misc_gen5.c
> index 9865f5b5b1..db662bb22a 100644
> --- a/arch/arm/mach-socfpga/misc_gen5.c
> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -182,15 +183,6 @@ int arch_early_init_r(void)
>  {
>   int i;
>  
> - /*
> -  * Write magic value into magic register to unlock support for
> -  * issuing warm reset. The ancient kernel code expects this
> -  * value to be written into the register by the bootloader, so
> -  * to support that old code, we write it here instead of in the
> -  * reset_cpu() function just before resetting the CPU.
> -  */
> - writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
> -
>   for (i = 0; i < 8; i++) /* Cache initial SW setting regs */
>   iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);
>  
> @@ -255,4 +247,43 @@ void do_bridge_reset(int enable)
>   writel(1, &nic301_regs->remap);
>   }
>  }
> +
> +/*
> + * This function controls the reboot behaviour via an environment callback to
> + * the variable "socfpga_reboot_from_sram".
> + *
> + * Setting this variable to 1 writes a magic value into a magic register that
> + * makes the Boot ROM jump to SRAM on a warm reset. Note that this doesn't
> + * happen on cold reset, and that the SPL is not CRC protected, so if it gets
> + * overwritten before boot, something bad will happen.
> + *
> + * Given these limitations, this env callback only exists for backwards
> + * compatibility.
> + */
> +static int on_socfpga_reboot_from_sram(const char *name, const char *value,
> +enum env_op op, int flags)
> +{
> + int val;
> + u32 reg;
> +
> + val = simple_strtoul(value, NULL, 10);
> + if (val) {
> + /*
> +  * Write magic value into magic register to unlock support for
> +  * issuing warm reset. The ancient kernel code expects this
> +  * value to be written into the register by the bootloader, so
> +  * to support that old code, we write it here instead of in the
> +  * reset_cpu() function just before resetting the CPU.
> +  */
> + reg = 0xae9efebc;
> + } else {
> + reg = 0;
> + }
> + writel(reg, &sysmgr_regs->romcodegrp_warmramgrp_enable);
> +
> + return 0;
> +}
> +
> +U_BOOT_ENV_CALLBACK(socfpga_reboot_from_sram, on_socfpga_reboot_from_sram);
> +
>  #endif
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index d1034ac280..aae4daf5d2 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -273,4 +273,9 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  #endif
>  #endif
>  
> +#ifndef CONFIG_ENV_CALLBACK_LIST_STATIC
> +#define CONFIG_ENV_CALLBACK_LIST_STATIC \
> + "socfpga_reboot_from_sram:socfpga_reboot_from_sram"
> +#endif
> +
>  #endif   /* __CONFIG_SOCFPGA_COMMON_H__ */
> 


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

Re: [U-Boot] [PATCH] cmd: reset: add parameters to specify reboot_mode

[Marek Vasut]

On 5/3/19 10:25 PM, Simon Goldschmidt wrote:
> This patch adds parameter support for the 'reset' command to specify
> the reboot mode (cold vs. warm).
> 
> Checking these parameters is implemented in the DM implementation.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
>  cmd/boot.c |  4 ++--
>  drivers/sysreset/sysreset-uclass.c | 17 -
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/cmd/boot.c b/cmd/boot.c
> index 9150fce80b..c3f33a9ca3 100644
> --- a/cmd/boot.c
> +++ b/cmd/boot.c
> @@ -56,9 +56,9 @@ U_BOOT_CMD(
>  #endif
>  
>  U_BOOT_CMD(
> - reset, 1, 0,do_reset,
> + reset, 2, 0,do_reset,
>   "Perform RESET of the CPU",
> - ""
> + "[] - type of reboot"
>  );
>  
>  #ifdef CONFIG_CMD_POWEROFF
> diff --git a/drivers/sysreset/sysreset-uclass.c 
> b/drivers/sysreset/sysreset-uclass.c
> index ad831c703a..fbda3f44f2 100644
> --- a/drivers/sysreset/sysreset-uclass.c
> +++ b/drivers/sysreset/sysreset-uclass.c
> @@ -111,9 +111,24 @@ void reset_cpu(ulong addr)
>  
>  int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>  {
> + enum sysreset_t reboot_mode = SYSRESET_COLD;
> +
> + if (argc > 1 && argv[1]) {
> + switch (*argv[1]) {
> + case 'w':
> + reboot_mode = SYSRESET_WARM;
> + printf("warm ");
> + break;
> + case 'c':
> + reboot_mode = SYSRESET_COLD;
> + printf("cold ");
> + break;

This looks like a platform or driver specific stuff ?

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

Re: [U-Boot] [PATCH] sysreset: add support for socfpga sysreset

[Marek Vasut]

On 5/3/19 10:21 PM, Simon Goldschmidt wrote:
> This moves sysreset support for socfgpa from ad-hoc code in mach-socfpga
> to a UCLASS_SYSRESET based dm driver.
> 
> A side effect is that gen5 and a10 can now differ between cold and warm
> reset.

s/differ/select/ ?

> Signed-off-by: Simon Goldschmidt 
> ---
> 
>  arch/arm/Kconfig  |  3 +
>  arch/arm/mach-socfpga/Makefile|  1 -
>  .../mach-socfpga/include/mach/reset_manager.h |  1 +
>  arch/arm/mach-socfpga/reset_manager.c | 41 -
>  drivers/sysreset/Kconfig  |  6 ++
>  drivers/sysreset/Makefile |  1 +
>  drivers/sysreset/sysreset_socfpga.c   | 58 +++
>  7 files changed, 69 insertions(+), 42 deletions(-)
>  delete mode 100644 arch/arm/mach-socfpga/reset_manager.c
>  create mode 100644 drivers/sysreset/sysreset_socfpga.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 49f01f1ff1..656ff92bd8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -823,6 +823,7 @@ config ARCH_SOCFPGA
>   select OF_CONTROL
>   select SPL_DM_RESET if DM_RESET
>   select SPL_DM_SERIAL
> + select SPL_DRIVERS_MISC_SUPPORT

Why MISC ?

>   select SPL_LIBCOMMON_SUPPORT
>   select SPL_LIBGENERIC_SUPPORT
>   select SPL_NAND_SUPPORT if SPL_NAND_DENALI
> @@ -833,6 +834,8 @@ config ARCH_SOCFPGA
>   select SUPPORT_SPL
>   select SYS_NS16550
>   select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
> + select SYSRESET
> + select SYSRESET_SOCFPGA
>   imply CMD_DM
>   imply CMD_MTDPARTS
>   imply CRC32_VERIFY
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
> index e66720447f..fc1181cb27 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -8,7 +8,6 @@
>  obj-y+= board.o
>  obj-y+= clock_manager.o
>  obj-y+= misc.o
> -obj-y+= reset_manager.o
>  
>  ifdef CONFIG_TARGET_SOCFPGA_GEN5
>  obj-y+= clock_manager_gen5.o
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> index 42beaecdd6..6ad037e325 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> @@ -11,6 +11,7 @@ void reset_cpu(ulong addr);
>  void socfpga_per_reset(u32 reset, int set);
>  void socfpga_per_reset_all(void);
>  
> +#define RSTMGR_CTRL_SWCOLDRSTREQ_LSB 0

Separate patch

>  #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1
>  
>  /*
> diff --git a/arch/arm/mach-socfpga/reset_manager.c 
> b/arch/arm/mach-socfpga/reset_manager.c
> deleted file mode 100644
> index e0a01ed07a..00
> --- a/arch/arm/mach-socfpga/reset_manager.c
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - *  Copyright (C) 2013 Altera Corporation 
> - */
> -
> -
> -#include 
> -#include 
> -#include 
> -
> -#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> -#include 
> -#endif
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> -static const struct socfpga_reset_manager *reset_manager_base =
> - (void *)SOCFPGA_RSTMGR_ADDRESS;
> -#endif
> -
> -/*
> - * Write the reset manager register to cause reset
> - */
> -void reset_cpu(ulong addr)
> -{
> - /* request a warm reset */
> -#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> - puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> - mbox_reset_cold();
> -#else
> - writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
> -&reset_manager_base->ctrl);
> -#endif
> - /*
> -  * infinite loop here as watchdog will trigger and reset
> -  * the processor
> -  */
> - while (1)
> - ;
> -}
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> index 8ce3e2e207..8b6e6626d2 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -36,6 +36,12 @@ config SYSRESET_PSCI
> Enable PSCI SYSTEM_RESET function call.  To use this, PSCI firmware
> must be running on your system.
>  
> +config SYSRESET_SOCFPGA
> + bool "Enable support for Intel SOCFPGA family"
> + depends on ARCH_SOCFPGA
> + help
> +   This enables the system reset driver support for Intel SOCFPGA SoCs.
> +
>  config SYSRESET_TI_SCI
>   bool "TI System Control Interface (TI SCI) system reset driver"
>   depends on TI_SCI_PROTOCOL
> diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
> index b3728ac17f..0241b0132d 100644
> --- a/drivers/sysreset/Makefile
> +++ b/drivers/sysreset/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
>  obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
>  obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
>  obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
> +obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
>  obj-$(CONFIG_SYSRESET_TI_SCI) 

Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early

[Andreas Dannenberg]

Simon,

On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote:
> Simon Glass  schrieb am Sa., 30. März 2019, 21:06:
> 
> > Hi Simon,
> >
> > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
> >  wrote:
> > >
> > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it
> > clears
> > > the bss before calling board_init_f() instead of clearing it before
> > calling
> > > board_init_r().
> > >
> > > This also ensures that variables placed in BSS can be shared between
> > > board_init_f() and board_init_r() in SPL.
> > >
> > > Such global variables are used, for example, when loading things from FAT
> > > before SDRAM is available: the full heap required for FAT uses global
> > > variables and clearing BSS after board_init_f() would reset the heap
> > state.
> > > An example for such a usage is socfpa_arria10 where an FPGA configuration
> > > is required before SDRAM can be used.
> > >
> > > Make the new option depend on ARM for now until more implementations
> > follow.
> > >
> >
> > I still have objections to this series and I think we should discuss
> > other ways of solving this problem.
> >
> > Does socfgpa have SRAM that could be used before SDRAM is available?
> > If so, can we not use that for the configuration? What various are
> > actually in BSS that are needed before board_init_r() is called? Can
> > they not be in a struct created from malloc()?
> >
> 
> The problem is the board needs to load an FPGA configuration from FAT
> before SDRAM is available. Yes, this is loaded into SRAM of course, but the
> whole code until that is done uses so many malloc/free iterations that The
> simple mall of implementation would require too much memory.
> 
> And it's the full malloc state variables only that use BSS, not the FAT
> code.

I've actually faced very similar issues working on our TI AM654x "System
Firmware Loader" implementation (will post upstream soon), where I need
to load this firmware and other files from media such as MMC/FAT in a very
memory-constrained SPL pre-relocation environment *before* I can bring up
DDR.

Initially, I modified the fat.c driver to re-use memory so it is not as
wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution [1]
this allowed us to get going, allowing to load multiple files without
issues in pre-relocation SPL.

In the quest of creating something more upstream-friendly I had then
switched to using full malloc in pre-relocation SPL so that I didn't
have to hack the FAT driver, encountering similar issues like you
brought up and got this working, but ultimately abandoned this
approach after bundling all files needed to get loaded into a single
image tree blob which no longer required any of those solutions.

What remained till today however is a need to preserve specific BSS
state from pre-relocation SPL over to post-relocation SPL environment,
namely flags set to avoid the (expensive) re-probing of peripheral
drivers by the SPL loader. For that I introduced a Kconfig option that
allows skipping the automatic clearing of BSS during relocation [2].

Seeing this very related discussion here got me thinking about how else
I can carry over this "state" from pre- to post relocation but that's
probably a discussion to be had once I post my "System Firmware Loader
Series", probably next week.

PS: If you want to save a ton of memory during FAT loading you can
try something like CONFIG_FS_FAT_MAX_CLUSTSIZE=16384, I argue the
default is overkill for all practical scenarios.

--
Andreas Dannenberg
Texas Instruments Inc

[1] 
http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=3de26c27d232425e6a3b337dc402d73fe22ea88c
[2] 
http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=9ab4a405c98e966a59c7c3005c08cb95ed87eea8

>
> One way out could be to move the full mall of state variables into 'gd'...
> 
> Another way would be to continue into board_init_f without SDRAM enabled
> and in it it later...
> 
> Regards,
> Simon
> 
> 
> > If this is a limitation of FAT, then I think we should fix that, instead.
> >
> > Regards,
> > Simon
> >
> > > Signed-off-by: Simon Goldschmidt 
> > > ---
> > >
> > > Changes in v3:
> > > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed
> > >
> > > Changes in v2:
> > > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now
> > >
> > >  common/spl/Kconfig | 12 
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > index 206c24076d..6a4270516a 100644
> > > --- a/common/spl/Kconfig
> > > +++ b/common/spl/Kconfig
> > > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN
> > >   to give board_init_r() a larger heap then the initial heap in
> > >   SRAM which is limited to SYS_MALLOC_F_LEN bytes.
> > >
> > > +config SPL_CLEAR_BSS_F
> > > +   bool "Clear BSS section before calling board_init_f"
> > > +   depends on ARM
> > > +   help
> > > + The BSS section is initialized to

[U-Boot] [PATCH] cmd: reset: add parameters to specify reboot_mode

[Simon Goldschmidt]

This patch adds parameter support for the 'reset' command to specify
the reboot mode (cold vs. warm).

Checking these parameters is implemented in the DM implementation.

Signed-off-by: Simon Goldschmidt 
---

 cmd/boot.c |  4 ++--
 drivers/sysreset/sysreset-uclass.c | 17 -
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/cmd/boot.c b/cmd/boot.c
index 9150fce80b..c3f33a9ca3 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -56,9 +56,9 @@ U_BOOT_CMD(
 #endif
 
 U_BOOT_CMD(
-   reset, 1, 0,do_reset,
+   reset, 2, 0,do_reset,
"Perform RESET of the CPU",
-   ""
+   "[] - type of reboot"
 );
 
 #ifdef CONFIG_CMD_POWEROFF
diff --git a/drivers/sysreset/sysreset-uclass.c 
b/drivers/sysreset/sysreset-uclass.c
index ad831c703a..fbda3f44f2 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -111,9 +111,24 @@ void reset_cpu(ulong addr)
 
 int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
+   enum sysreset_t reboot_mode = SYSRESET_COLD;
+
+   if (argc > 1 && argv[1]) {
+   switch (*argv[1]) {
+   case 'w':
+   reboot_mode = SYSRESET_WARM;
+   printf("warm ");
+   break;
+   case 'c':
+   reboot_mode = SYSRESET_COLD;
+   printf("cold ");
+   break;
+   }
+   }
+
printf("resetting ...\n");
 
-   sysreset_walk_halt(SYSRESET_COLD);
+   sysreset_walk_halt(reboot_mode);
 
return 0;
 }
-- 
2.20.1

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

[U-Boot] [PATCH] sysreset: add support for socfpga sysreset

[Simon Goldschmidt]

This moves sysreset support for socfgpa from ad-hoc code in mach-socfpga
to a UCLASS_SYSRESET based dm driver.

A side effect is that gen5 and a10 can now differ between cold and warm
reset.

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/Kconfig  |  3 +
 arch/arm/mach-socfpga/Makefile|  1 -
 .../mach-socfpga/include/mach/reset_manager.h |  1 +
 arch/arm/mach-socfpga/reset_manager.c | 41 -
 drivers/sysreset/Kconfig  |  6 ++
 drivers/sysreset/Makefile |  1 +
 drivers/sysreset/sysreset_socfpga.c   | 58 +++
 7 files changed, 69 insertions(+), 42 deletions(-)
 delete mode 100644 arch/arm/mach-socfpga/reset_manager.c
 create mode 100644 drivers/sysreset/sysreset_socfpga.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49f01f1ff1..656ff92bd8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -823,6 +823,7 @@ config ARCH_SOCFPGA
select OF_CONTROL
select SPL_DM_RESET if DM_RESET
select SPL_DM_SERIAL
+   select SPL_DRIVERS_MISC_SUPPORT
select SPL_LIBCOMMON_SUPPORT
select SPL_LIBGENERIC_SUPPORT
select SPL_NAND_SUPPORT if SPL_NAND_DENALI
@@ -833,6 +834,8 @@ config ARCH_SOCFPGA
select SUPPORT_SPL
select SYS_NS16550
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+   select SYSRESET
+   select SYSRESET_SOCFPGA
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e66720447f..fc1181cb27 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -8,7 +8,6 @@
 obj-y  += board.o
 obj-y  += clock_manager.o
 obj-y  += misc.o
-obj-y  += reset_manager.o
 
 ifdef CONFIG_TARGET_SOCFPGA_GEN5
 obj-y  += clock_manager_gen5.o
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 42beaecdd6..6ad037e325 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -11,6 +11,7 @@ void reset_cpu(ulong addr);
 void socfpga_per_reset(u32 reset, int set);
 void socfpga_per_reset_all(void);
 
+#define RSTMGR_CTRL_SWCOLDRSTREQ_LSB 0
 #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1
 
 /*
diff --git a/arch/arm/mach-socfpga/reset_manager.c 
b/arch/arm/mach-socfpga/reset_manager.c
deleted file mode 100644
index e0a01ed07a..00
--- a/arch/arm/mach-socfpga/reset_manager.c
+++ /dev/null
@@ -1,41 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- *  Copyright (C) 2013 Altera Corporation 
- */
-
-
-#include 
-#include 
-#include 
-
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-#include 
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-static const struct socfpga_reset_manager *reset_manager_base =
-   (void *)SOCFPGA_RSTMGR_ADDRESS;
-#endif
-
-/*
- * Write the reset manager register to cause reset
- */
-void reset_cpu(ulong addr)
-{
-   /* request a warm reset */
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-   puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
-   mbox_reset_cold();
-#else
-   writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
-  &reset_manager_base->ctrl);
-#endif
-   /*
-* infinite loop here as watchdog will trigger and reset
-* the processor
-*/
-   while (1)
-   ;
-}
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..8b6e6626d2 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -36,6 +36,12 @@ config SYSRESET_PSCI
  Enable PSCI SYSTEM_RESET function call.  To use this, PSCI firmware
  must be running on your system.
 
+config SYSRESET_SOCFPGA
+   bool "Enable support for Intel SOCFPGA family"
+   depends on ARCH_SOCFPGA
+   help
+ This enables the system reset driver support for Intel SOCFPGA SoCs.
+
 config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index b3728ac17f..0241b0132d 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
 obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
 obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
 obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
 obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
 obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
 obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga.c 
b/drivers/sysreset/sysreset_socfpga.c
new file mode 100644
index 00..b5bbf4aad6
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga.c
@@ -0,0 +1,5

Re: [U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode

[Trent Piepho]

On Thu, 2019-05-02 at 08:11 +0200, Anatolij Gustschin wrote:
> Hi Heiko,
> 
> On Thu, 2 May 2019 07:39:06 +0200
> Heiko Schocher h...@denx.de wrote:
> ...
> > 
> > @Anatolij: Is this code needed anymore, as board is moved to DM ?
> 
> ...
> > dm_i2c_probe should initialize the i2c bus completly, also we need
> > not longer the:
> > 
> > #ifdef CONFIG_DM_I2C
> > 
> > and remove the else part ... or ? Can you test this change?
> 
> The DM conversion is not complete yet and I still need the
> possibility to revert to non-DM code for various video tests
> to complete the DM_VIDEO/DM_I2C conversion, so that video
> related stuff works on i.MX boards similar as before the
> conversion. Unfortunately, I do not have time for this now,
> this must wait. Sorry.
> 
> Anatolij

Would something like this be ok?  It will allow removing the MXC
hardcoded speeds when using DM_I2C.  It also makes it more clear in
wandboard.c that the speed is not used when using DM_I2C.

--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -46,6 +46,15 @@ DECLARE_GLOBAL_DATA_PTR;
 #define ETH_PHY_AR8035_POWER   IMX_GPIO_NR(7, 13)
 #define REV_DETECTION  IMX_GPIO_NR(2, 28)
  
+/* Speed defined in Kconfig is only applicable when not using DM_I2C.  */
+#ifdef CONFIG_DM_I2C
+#define I2C1_SPEED_NON_DM  0
+#define I2C2_SPEED_NON_DM  0
+#else
+#define I2C1_SPEED_NON_DM  CONFIG_SYS_MXC_I2C1_SPEED
+#define I2C2_SPEED_NON_DM  CONFIG_SYS_MXC_I2C2_SPEED
+#endif
+
 static bool with_pmic;
  
 int dram_init(void)
@@ -463,13 +472,13 @@ int board_init(void)
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
  
 #if defined(CONFIG_VIDEO_IPUV3)
-   setup_i2c(1, CONFIG_SYS_MXC_I2C1_SPEED, 0x7f, &mx6dl_i2c2_pad_info);
+   setup_i2c(1, I2C1_SPEED_NON_DM, 0x7f, &mx6dl_i2c2_pad_info);
if (is_mx6dq() || is_mx6dqp()) {
-   setup_i2c(1, CONFIG_SYS_MXC_I2C1_SPEED, 0x7f, 
&mx6q_i2c2_pad_info);
-   setup_i2c(2, CONFIG_SYS_MXC_I2C2_SPEED, 0x7f, 
&mx6q_i2c3_pad_info);
+   setup_i2c(1, I2C1_SPEED_NON_DM, 0x7f, &mx6q_i2c2_pad_info);
+   setup_i2c(2, I2C2_SPEED_NON_DM, 0x7f, &mx6q_i2c3_pad_info);
} else {
-   setup_i2c(1, CONFIG_SYS_MXC_I2C1_SPEED, 0x7f, 
&mx6dl_i2c2_pad_info);
-   setup_i2c(2, CONFIG_SYS_MXC_I2C2_SPEED, 0x7f, 
&mx6dl_i2c3_pad_info);
+   setup_i2c(1, I2C1_SPEED_NON_DM, 0x7f, &mx6dl_i2c2_pad_info);
+   setup_i2c(2, I2C2_SPEED_NON_DM, 0x7f, &mx6dl_i2c3_pad_info);
}
  
setup_display();
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Simon Goldschmidt]

This moves the code that enables the Boot ROM to just jump to SRAM instead
of loading SPL from the original boot source on warm reboot.

Instead of always enabling this, an environment callback for the env var
"socfpga_reboot_from_sram" is used. This way, the behaviour can be enabled
at runtime and via saved environment.

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/mach-socfpga/misc_gen5.c | 49 +--
 include/configs/socfpga_common.h  |  5 
 2 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
b/arch/arm/mach-socfpga/misc_gen5.c
index 9865f5b5b1..db662bb22a 100644
--- a/arch/arm/mach-socfpga/misc_gen5.c
+++ b/arch/arm/mach-socfpga/misc_gen5.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -182,15 +183,6 @@ int arch_early_init_r(void)
 {
int i;
 
-   /*
-* Write magic value into magic register to unlock support for
-* issuing warm reset. The ancient kernel code expects this
-* value to be written into the register by the bootloader, so
-* to support that old code, we write it here instead of in the
-* reset_cpu() function just before resetting the CPU.
-*/
-   writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
-
for (i = 0; i < 8; i++) /* Cache initial SW setting regs */
iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);
 
@@ -255,4 +247,43 @@ void do_bridge_reset(int enable)
writel(1, &nic301_regs->remap);
}
 }
+
+/*
+ * This function controls the reboot behaviour via an environment callback to
+ * the variable "socfpga_reboot_from_sram".
+ *
+ * Setting this variable to 1 writes a magic value into a magic register that
+ * makes the Boot ROM jump to SRAM on a warm reset. Note that this doesn't
+ * happen on cold reset, and that the SPL is not CRC protected, so if it gets
+ * overwritten before boot, something bad will happen.
+ *
+ * Given these limitations, this env callback only exists for backwards
+ * compatibility.
+ */
+static int on_socfpga_reboot_from_sram(const char *name, const char *value,
+  enum env_op op, int flags)
+{
+   int val;
+   u32 reg;
+
+   val = simple_strtoul(value, NULL, 10);
+   if (val) {
+   /*
+* Write magic value into magic register to unlock support for
+* issuing warm reset. The ancient kernel code expects this
+* value to be written into the register by the bootloader, so
+* to support that old code, we write it here instead of in the
+* reset_cpu() function just before resetting the CPU.
+*/
+   reg = 0xae9efebc;
+   } else {
+   reg = 0;
+   }
+   writel(reg, &sysmgr_regs->romcodegrp_warmramgrp_enable);
+
+   return 0;
+}
+
+U_BOOT_ENV_CALLBACK(socfpga_reboot_from_sram, on_socfpga_reboot_from_sram);
+
 #endif
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index d1034ac280..aae4daf5d2 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -273,4 +273,9 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #endif
 #endif
 
+#ifndef CONFIG_ENV_CALLBACK_LIST_STATIC
+#define CONFIG_ENV_CALLBACK_LIST_STATIC \
+   "socfpga_reboot_from_sram:socfpga_reboot_from_sram"
+#endif
+
 #endif /* __CONFIG_SOCFPGA_COMMON_H__ */
-- 
2.20.1

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

Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller

[Marek Vasut]

On 5/3/19 7:56 PM, Ang, Chee Hong wrote:
> On Fri, 2019-05-03 at 19:04 +0200, Marek Vasut wrote:
>> On 5/3/19 5:53 PM, Ang, Chee Hong wrote:
>>>
>>> On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:

 On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
>
>
> From: "Ang, Chee Hong" 
 Commit message is missing -- why do you need to enable the DMA330
 ?

 Don't you have a reset driver, like A10 and Gen5 ?
>>> DMA driver for S10 is still missing in u-boot. I need to enable
>>> this
>>> for booting Linux which is required by Linux's DMA driver.
>>> I will add the reason to enable DMA330 in the commit message.
>> Can you also answer my question regarding the reset driver ?
> Yes. S10 has a reset driver in drivers/reset/reset-socfpga.c.

So why don't you use it ? :-)

> Signed-off-by: Ang, Chee Hong 
> ---
>  arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1 +
>  arch/arm/mach-socfpga/spl_s10.c| 4
> 
>  2 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-
> socfpga/include/mach/reset_manager_s10.h 
> b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> index e186296..3ac46c3 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
>  #define RSTMGR_DMA   RSTMGR_DEFINE(1, 16)
>  #define RSTMGR_SPIM0 RSTMGR_DEFINE(1, 17)
>  #define RSTMGR_SPIM1 RSTMGR_DEFINE(1, 18)
> +#define RSTMGR_DMA_OCP   RSTMGR_DEFINE(1, 21)
>  #define RSTMGR_L4WD0 RSTMGR_DEFINE(2, 0)
>  #define RSTMGR_L4WD1 RSTMGR_DEFINE(2, 1)
>  #define RSTMGR_L4WD2 RSTMGR_DEFINE(2, 2)
> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-
> socfpga/spl_s10.c
> index a141ffe..e063229 100644
> --- a/arch/arm/mach-socfpga/spl_s10.c
> +++ b/arch/arm/mach-socfpga/spl_s10.c
> @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
>   writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
> &sysmgr_regs->dma);
>   writel(SYSMGR_DMAPERIPH_ALL_NS, &sysmgr_regs-
>> dma_periph);
>  
> + /* enable DMA330 DMA */
> + socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> + socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
> +
>   spl_disable_firewall_l4_per();
>  
>   spl_disable_firewall_l4_sys();
>


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

[U-Boot] [PATCH] fdt_shrink_to_minimum: do not mark fdt space reserved unconditionally

[Simon Goldschmidt]

This function merely relocates the fdt blob, so don't let it alter
it by adding reservations that didn't exist before.

Instead, if the memory used for the fdt blob has been reserved
before calling this function, ensure the relocated memory is
marked as reserved instead.

Reported-by: Keerthy 
Reported-by: Lokesh Vutla 
Signed-off-by: Simon Goldschmidt 
---

 common/fdt_support.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index ab08a0114f..4e7cf6ebe9 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -597,6 +597,7 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
uint64_t addr, size;
int total, ret;
uint actualsize;
+   int fdt_memrsv = 0;
 
if (!blob)
return 0;
@@ -606,6 +607,7 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
fdt_get_mem_rsv(blob, i, &addr, &size);
if (addr == (uintptr_t)blob) {
fdt_del_mem_rsv(blob, i);
+   fdt_memrsv = 1;
break;
}
}
@@ -627,10 +629,12 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
/* Change the fdt header to reflect the correct size */
fdt_set_totalsize(blob, actualsize);
 
-   /* Add the new reservation */
-   ret = fdt_add_mem_rsv(blob, map_to_sysmem(blob), actualsize);
-   if (ret < 0)
-   return ret;
+   if (fdt_memrsv) {
+   /* Add the new reservation */
+   ret = fdt_add_mem_rsv(blob, map_to_sysmem(blob), actualsize);
+   if (ret < 0)
+   return ret;
+   }
 
return actualsize;
 }
-- 
2.20.1

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

Re: [U-Boot] [PATCH] board_f: Do not mark pre-relocated fdt space as reserved

[Simon Goldschmidt]

Hi Lokesh,

On 03.05.19 16:24, Lokesh Vutla wrote:

Simon,

On 22/04/19 8:15 PM, Tom Rini wrote:

On Thu, Apr 18, 2019 at 08:23:45AM +0200, Simon Goldschmidt wrote:

On Thu, Apr 18, 2019 at 8:12 AM Lokesh Vutla  wrote:




On 18/04/19 12:46 AM, Simon Goldschmidt wrote:

[This is a follow-up to https://patchwork.ozlabs.org/patch/1033584/ right?]


Right.



Am 16.04.2019 um 10:43 schrieb Lokesh Vutla:

SPL while copying u-boot and dtb it does the following:
- Copy u-boot
- Copy right dtb.
- mark dtb location as reserved in dtb.


Hmm, why does it do that? Reserving space when U-Boot starts Linux *might* make
sense, but why should SPL add this reservation when starting U-Boot? These steps
are for U-Boot in a fit-image, right? Because I can't see this for U-Boot as
uImage.

Am I correct that 'fdt_shrink_to_minimum()' adds this reservation? The name of
that function doesn't suggest that to me. Would it make more sense to let this
funtion only *change* the reservation, i.e. only add it if it is removed at the
beginning of said function? Would that fix your issue?

Something like this:

diff --git a/common/fdt_support.c b/common/fdt_support.c
index ab08a0114f..4e7cf6ebe9 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -597,6 +597,7 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
 uint64_t addr, size;
 int total, ret;
 uint actualsize;
+   int fdt_memrsv = 0;

 if (!blob)
 return 0;
@@ -606,6 +607,7 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
 fdt_get_mem_rsv(blob, i, &addr, &size);
 if (addr == (uintptr_t)blob) {
 fdt_del_mem_rsv(blob, i);
+   fdt_memrsv = 1;
 break;
 }
 }
@@ -627,10 +629,12 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
 /* Change the fdt header to reflect the correct size */
 fdt_set_totalsize(blob, actualsize);

-   /* Add the new reservation */
-   ret = fdt_add_mem_rsv(blob, map_to_sysmem(blob), actualsize);
-   if (ret < 0)
-   return ret;
+   if (fdt_memrsv) {
+   /* Add the new reservation */
+   ret = fdt_add_mem_rsv(blob, map_to_sysmem(blob), actualsize);
+   if (ret < 0)
+   return ret;
+   }


Agreed. This works and more appropriate place to fix it. Will you post a
separate patch or do you want me to post it on your behalf?


While it's good to know this fixes your issue, I'm not sure this doesn't break
anything else.

Tom, Simon, can you add anything here? Why is the dtb memory added as
reserved to itself? It seems to me this is redundant, as the code using the
dtb should well know the pointer to it...

Lokesh, I can send a patch once this is discussed.


OK, so the history of that call is really what's seen in:
commit 41c5eaa7253ed82bbae1eda5667755872c615164
Author: Andy Fleming 
Date:   Mon Jun 16 13:58:56 2008 -0500

 Resize device tree to allow space for board changes and the chosen node
 
 Current code requires that a compiled device tree have space added to the end to

 leave room for extra nodes added by board code (and the chosen node).  This
 requires that device tree creators anticipate how much space U-Boot will 
add to
 the tree, which is absurd.  Ideally, the code would resize and/or relocate 
the
 tree when it needed more space, but this would require a systemic change 
to the
 fdt code, which is non-trivial.  Instead, we resize the tree inside
 boot_relocate_fdt, reserving either the remainder of the bootmap (in the 
case
 where the fdt is inside the bootmap), or adding CFG_FDT_PAD bytes to the 
size.
 
 Signed-off-by: Andy Fleming 


Which is all about preparing things for passing the device tree we
loaded specifically for Linux.  In:
commit 3082d2348c8e13342f5fdd10e9b3f7408062dbf9
Author: Kumar Gala 
Date:   Fri Aug 15 08:24:42 2008 -0500

 fdt: refactor fdt resize code
 
 Move the fdt resizing code out of ppc specific boot code and into

 common fdt support code.
 
 Signed-off-by: Kumar Gala 


The code was moved to a more common area.  So the intent on "reserve"
was to make sure that we had enough space set aside for the dtb to be
able to be updated at runtime, by U-Boot, for various needs and that we
wouldn't give that memory away to something else / allow it to be
clobbered.



Any update on this? Any chance you will be posting your changes?


No, sorry, not update. I'll send the patch I suggested above and we'll 
see how the discussion continues.


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

Re: [U-Boot] ARM: omap3_logic: Enable UUID

[Fabio Estevam]

Hi Stefano,

On Fri, Apr 26, 2019 at 7:11 AM  wrote:
>
> > Instead of hardcoding the mmcroot to /dev/mmcblkX, use the UUID
> > method.
> > Signed-off-by: Adam Ford 
> > diff --git a/configs/omap35_logic_defconfig b/configs/omap35_logic_defconfig
> > index 5b5f3eb7b4..9a1596c89b 100644
> > --- a/configs/omap35_logic_defconfig
> > +++ b/configs/omap35_logic_defconfig

> Applied to u-boot-imx, master, thanks !

Was this applied to the u-boot-imx tree by mistake?

This patch is for omap, not i.MX :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] lib: Kconfig: fix help text for GZIP

[Tom Rini]

On Mon, Apr 29, 2019 at 08:59:38AM +0200, Heiko Schocher wrote:

> commit 95f4bbd581cf ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
> 
> introduced Kconfig option for gzip in U-Boot, but help text
> says gzip for SPL, which is wrong. Fix this.
> 
> Signed-off-by: Heiko Schocher 
> Acked-by: Marek Vasut 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: dts: logicpd-som-lv: Fix MMC1 card detect

[Tom Rini]

On Tue, Apr 30, 2019 at 07:53:16AM -0500, Adam Ford wrote:

> The card detect pin was incorrectly using IRQ_TYPE_LEVEL_LOW
> instead of GPIO_ACTIVE_LOW when reading the state of the CD pin.
> 
> Without this patch, MMC1 won't be detected.
> 
> This is the same patch submitted to linux-omap, but I was hoping
> to get it applied to U-Boot without having to wait for the
> linux adoption and then backporting.
> 
> Fixes: 5448ff33f281 ("ARM: DTS: Resync Logic PD SOM-LV 37xx
> devkit with Linux 4.18-RC4")
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi 
> b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
> index 4990ed90dc..3524766515 100644

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] fs: btrfs: fix btrfs methods return values on failure

[Tom Rini]

On Thu, May 02, 2019 at 03:28:43PM +0200, Marek Behún wrote:

> The btrfs implementation methods .ls(), .size() and .read() returns 1 on
> failure, but the command handlers expect values <0 on failure.
> 
> For example if given a nonexistent path, the load command currently
> returns success, and hush scripting does not work.
> 
> Fix this by setting return values of these methods to -1 instead of 1 on
> failure.
> 
> Signed-off-by: Marek Behún 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] lib/vsprintf: remove #include from vsprintf.c

[Tom Rini]

On Mon, Apr 29, 2019 at 08:04:36AM +0200, Heinrich Schuchardt wrote:

> common.h already includes uuid.h
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] fs: correct comments for fs_read() and write()

[Tom Rini]

On Thu, Apr 25, 2019 at 08:36:39PM +0200, Heinrich Schuchardt wrote:

> The existing comments where confusing read and write. The comment for
> fs_write() had:
> "@addr: The address to read into"
> 
> So let's rework the comments and format them in Sphinx style.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 1/1] at91: cleanup taurus port

[Tom Rini]

On Mon, Apr 29, 2019 at 04:36:10PM +0200, Heiko Schocher wrote:

> - at91sam9g20-taurus.dts: use labels
> - cleanup taurus port to compile clean with
>   current mainline again. SPL has no serial
>   output anymore, so it fits into SRAM.
> 
> Signed-off-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] firmware: ti_sci: Always request response from firmware

[Tom Rini]

On Mon, Apr 29, 2019 at 09:04:11AM -0400, Andrew F. Davis wrote:

> TI-SCI firmware will only respond to messages when the
> TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages
> already do this, set this for the ones that do not.
> 
> Signed-off-by: Andrew F. Davis 
> Tested-by: Alejandro Hernandez 
> Acked-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] tools/Makefile: fix HOSTCFLAGS with CROSS_BUILD_TOOLS

[Tom Rini]

On Wed, May 01, 2019 at 03:08:25PM +0200, Fabrice Fontaine wrote:

> When CROSS_BUILD_TOOLS is set, set HOSTCFLAGS to CFLAGS otherwise CC
> will be used with HOSTCFLAGS which seems wrong
> 
> Signed-off-by: Fabrice Fontaine 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] ti: Add device-tree for am335x-pocketbeagle.

[Tom Rini]

On Mon, Apr 29, 2019 at 04:12:29PM -0700, Vagrant Cascadian wrote:

> Add device-tree files from linux 5.1-rc7 needed to complete support
> for PocketBeagle.
> 
> Signed-off-by: Vagrant Cascadian 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.

[Tom Rini]

On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote:

> Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig.
> 
> Signed-off-by: Vagrant Cascadian 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] fs: btrfs: Do not print mount fail message when not btrfs filesystem

[Tom Rini]

On Fri, Apr 26, 2019 at 03:11:09PM +0200, Marek Behún wrote:

> Other filesystem drivers don't do this.
> 
> Signed-off-by: Marek Behún 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] board: am335x: Drop duplicate pinmux configuration

[Tom Rini]

On Thu, Apr 25, 2019 at 03:12:00PM +0100, p...@betafive.co.uk wrote:

> From: Paul Barker 
> 
> In commit ad6054f1fe128f797b6eb2964afca6674b584785 where support for the
> Sancloud BeagleBone Enhanced (BBE) was added, new conditional
> configuration of either MII pin muxing or RGMII pin muxing is done
> depending on the board type. However, the old call to set up MII pin
> muxing was not removed.
> 
> This may result in misconfiguration of the pin muxing for the BBE or
> duplicate configuration for other boards and so we remove this obsolete
> call.
> 
> Signed-off-by: Paul Barker 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] armv7R: dts: k3: am654: Switch DMSC TX message thread ID

[Tom Rini]

On Thu, Apr 25, 2019 at 12:27:02PM -0500, Andreas Dannenberg wrote:

> Switch from using the high priority DMSC transmit message queue used
> by the secure R5 MCU island boot context to the low priority message
> queue. While the change in priority is irrelevant for the current boot
> architecture it however gives us access to a deeper message queue that
> will allow us to buffer more messages. This is an important aspect when
> sending several messages without requesting and waiting for a response
> in a row which is a communication scheme used during core shutdown for
> example. See AM654 TISCI User Guide for additional details.
> 
> Signed-off-by: Andreas Dannenberg 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] arm: dts: k3-am654: Sync IOPAD macros with Linux

[Tom Rini]

On Mon, Apr 29, 2019 at 12:56:44PM -0500, Andreas Dannenberg wrote:

> Transition to the IOPAD macros as used in Linux in which the pin mux
> mode is specified using a dedicated parameter while also dropping the
> related MUX_MODEx macros that are no longer needed. This transition
> will allow us to keep both Linux and U-Boot DTS in sync more easily.
> While at it also align the file name of the include file itself and
> update any references accordingly.
> 
> Signed-off-by: Andreas Dannenberg 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] README: davinci: update the documentation for DaVinci

[Tom Rini]

On Tue, Apr 30, 2019 at 09:39:25AM +0200, Bartosz Golaszewski wrote:

> From: Bartosz Golaszewski 
> 
> The DM* family of SOCs is no longer supported. We now support the
> omap-l138 lcdk board and Lego EV3 platform. Reflect those changes
> in the README.
> 
> Signed-off-by: Bartosz Golaszewski 
> Reviewed-by: Sekhar Nori 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] dma: ti: k3-udma: Do not touch RT registers before channel configuration

[Tom Rini]

On Thu, Apr 25, 2019 at 12:08:15PM +0530, Vignesh Raghavendra wrote:

> From: Peter Ujfalusi 
> 
> Upcoming sysfw (2019.03) will not open the channelized firewalls during
> init, it only going to do so in response to the channel configuration
> message.
> 
> Remove the channel state checks done before the channel configuration and
> move it after the configuration for warning purposes.
> 
> Signed-off-by: Peter Ujfalusi 
> Signed-off-by: Vignesh Raghavendra 
> Reviewed-by: Grygorii Strashko 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] watchdog: Kconfig: update WDT help message

[Tom Rini]

On Thu, Apr 25, 2019 at 12:57:28PM +0200, Patrice Chotard wrote:

> Restart operation never exists and reset operation never
> makes the watchdog expire immediately but expire_now operation
> does.
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Stefan Roese 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] drivers: dma: ti: k3-udma: Extract packet data only when Meta data is not NULL

[Tom Rini]

On Wed, Apr 24, 2019 at 04:33:54PM +0530, Keerthy wrote:

> Currently packet data is wrongly extracted when metadata is NULL.
> Fix it and negate the if check.
> 
> Signed-off-by: Keerthy 
> Reviewed-by: Grygorii Strashko 
> Reviewed-by: Peter Ujfalusi 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] firmware: ti_sci: Fix TISCI mailbox receive timeout handling

[Tom Rini]

On Wed, Apr 24, 2019 at 02:20:08PM -0500, Andreas Dannenberg wrote:

> An earlier commit converted the TISCI receive timeouts to be specified
> in ms rather than us however it failed to take this change into account
> when passing the actual timeout to be used when invoking the mailbox
> receive API. This leads to the actual timeout to be 1,000 times shorter
> than expected and as a result certain TISCI operations would fail.
> 
> Fix the issue by converting the timeout declared in ms to us on the fly
> as expected by the respective API.
> 
> Fixes: fd6b40b1ba20 ("firmware: ti_sci: Add support for NAVSS resource 
> management")
> Signed-off-by: Andreas Dannenberg 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] MAINTAINERS, git-mailrc: Update the mmc maintainer

[Tom Rini]

On Wed, Apr 24, 2019 at 11:56:58AM +, Peng Fan wrote:

> Update the mmc maintainer from Jaehoon to me.
> 
> Cc: Jaehoon Chung 
> Signed-off-by: Peng Fan 
> Acked-by: Marek Vasut 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL, RESEND] Please pull u-boot-rockchip/tags/rockchip-for-2019.07

[Tom Rini]

On Fri, May 03, 2019 at 04:09:27PM +0200, Philipp Tomsich wrote:

> Tom,
> 
> [resend due to me forgetting to CC the mailing-list]
> 
> Here’s the first batch of changes for the Rockchip side of the repository.
> Took a bit longer as expected as there always was ‘one more issue’ to fix up 
> during
> the merge…
> 
> Clean bill-of-health in Travis-CI at
>   https://travis-ci.org/ptomsich/u-boot-rockchip/builds/526773500
> 
> Thanks,
> Philipp.
> 
> The following changes since commit a69120a0d7c8d4044cdaceea9eb03913ba4e49c7:
> 
>  Prepare v2019.07-rc1 (2019-04-29 21:54:04 -0400)
> 
> are available in the git repository at:
> 
>  git://git.denx.de/u-boot-rockchip.git tags/rockchip-for-2019.07
> 
> for you to fetch changes up to dd320e122f78312b99cdbfb085a0ad167a396bb5:
> 
>  rockchip: rk3288: include header for back_to_bootrom (2019-05-01 09:40:59 
> +0200)
> 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2

[Tom Rini]

On Fri, May 03, 2019 at 07:27:40AM +0200, Heinrich Schuchardt wrote:

> The following changes since commit b4ee6daad7a2604ca9466b2ba48de86cc27d381f:
> 
>   Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx
> (2019-05-01 07:25:51 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2
> 
> for you to fetch changes up to 4ccf678f37731d8ec09eae8dca5f4cbe84132a52:
> 
>   lib: uuid: Fix unseeded PRNG on RANDOM_UUID=y (2019-05-02 18:17:50 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

[Michal Simek]

On 03. 05. 19 11:04, Tom Rini wrote:
> On Fri, May 03, 2019 at 10:49:34AM -0700, Michal Simek wrote:
>> On 03. 05. 19 10:35, Tom Rini wrote:
>>> On Fri, May 03, 2019 at 09:29:32AM -0700, Michal Simek wrote:
>>> [snip]
 I think we need to get more clarity what exactly vxworks expects and
 what are just your "hacks" to get it work.
 If vxworks deviates existing dt binding, or create completely new one.
>>>
>>> Hold up.  If it's not in the spec itself (and most stuff is not), the
>>> Linux bindings are no more authoritative than the BSD ones (which are
>>> also not, unless things have changed, the Linux ones) than the vxWorks
>>> ones than anything else.  For a board that is not supported in Linux, I
>>> don't think it makes sense to treat the primary OS support as something
>>> that's added to another DT.
>>
>> This board is using u-boot which is using linux binding. It means this
>> should be IMHO in separate file from the rest what vxworks expects.
>> Then we can review u-boot configurations properly.
> 
> I see.  I've always looked at it as "primary OS + u-boot additions in
> another file".  When we use bindings they are the Linux ones, yes (when
> they aren't our own things).  I've always seen it as making sync with
> the authoritative DTS for the HW easy as why we copy Linux and add to
> it.  The end goal to me is to make sure that DTS maintenance is easy on
> the HW owner.


But still you can do right split with soc dtsi/clock dtsi/board/vxworks.

And we have done a decision long time ago in Linux and also the same
decision was taken to u-boot that mainline DT file won't contain any
fpga/pl description.
If you still want to do it that you should pack dt overlay with
bitstream to FIT and let u-boot to do the job.
But this PL overlay shouldn't land in mainline.

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

Re: [U-Boot] [PATCH v2] imx: Use a convenient default value for SYS_MALLOC_F_LEN

[Bryan O'Donoghue]

On 03/05/2019 18:05, Fabio Estevam wrote:

Commit 3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to
simple-bus driver") causes some i.MX boards that were converted
to DM, such as warp7, to fail to boot.

As explained by Lukas Auer:

"With the patch, U-Boot probes the drivers for devices under simple-bus
device tree nodes in the pre-relocation device model. The default value
of CONFIG_SYS_MALLOC_F_LEN (0x400) leaves U-Boot with not enough memory to
do this, causing it to hang."

Fix this problem by providing a convenient default value for
CONFIG_SYS_MALLOC_F_LEN.

Reported-by: Pierre-Jean Texier 
Suggested-by: Lukas Auer 
Signed-off-by: Fabio Estevam 


Good work.

Tested: warp7_bl33, warp7

Tested-by: Bryan O'Donoghue 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

[Tom Rini]

On Fri, May 03, 2019 at 10:49:34AM -0700, Michal Simek wrote:
> On 03. 05. 19 10:35, Tom Rini wrote:
> > On Fri, May 03, 2019 at 09:29:32AM -0700, Michal Simek wrote:
> > [snip]
> >> I think we need to get more clarity what exactly vxworks expects and
> >> what are just your "hacks" to get it work.
> >> If vxworks deviates existing dt binding, or create completely new one.
> > 
> > Hold up.  If it's not in the spec itself (and most stuff is not), the
> > Linux bindings are no more authoritative than the BSD ones (which are
> > also not, unless things have changed, the Linux ones) than the vxWorks
> > ones than anything else.  For a board that is not supported in Linux, I
> > don't think it makes sense to treat the primary OS support as something
> > that's added to another DT.
> 
> This board is using u-boot which is using linux binding. It means this
> should be IMHO in separate file from the rest what vxworks expects.
> Then we can review u-boot configurations properly.

I see.  I've always looked at it as "primary OS + u-boot additions in
another file".  When we use bindings they are the Linux ones, yes (when
they aren't our own things).  I've always seen it as making sync with
the authoritative DTS for the HW easy as why we copy Linux and add to
it.  The end goal to me is to make sure that DTS maintenance is easy on
the HW owner.

-- 
Tom


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

[U-Boot] [PATCH 2/3] bcm963158: remove CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT

[Philippe Reynes]

This board define the flag CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
but it's a mistake. It's a workaround for an issue in nand core.
This issue was fixed by the commit 5f626e78491c ("mtd: nand: raw:
Fix CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT behavior"). Now, this flag
break the nand on this board, so we simply remove it.

Signed-off-by: Philippe Reynes 
---
 include/configs/broadcom_bcm963158.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/broadcom_bcm963158.h 
b/include/configs/broadcom_bcm963158.h
index 2de6f21..a0f7ead 100644
--- a/include/configs/broadcom_bcm963158.h
+++ b/include/configs/broadcom_bcm963158.h
@@ -34,7 +34,6 @@
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_SELF_INIT
 #define CONFIG_SYS_NAND_ONFI_DETECTION
-#define CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
 #endif /* CONFIG_NAND */
 
 /*
-- 
2.7.4

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

Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller

[Ang, Chee Hong]

On Fri, 2019-05-03 at 19:04 +0200, Marek Vasut wrote:
> On 5/3/19 5:53 PM, Ang, Chee Hong wrote:
> > 
> > On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
> > > 
> > > On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
> > > > 
> > > > 
> > > > From: "Ang, Chee Hong" 
> > > Commit message is missing -- why do you need to enable the DMA330
> > > ?
> > > 
> > > Don't you have a reset driver, like A10 and Gen5 ?
> > DMA driver for S10 is still missing in u-boot. I need to enable
> > this
> > for booting Linux which is required by Linux's DMA driver.
> > I will add the reason to enable DMA330 in the commit message.
> Can you also answer my question regarding the reset driver ?
Yes. S10 has a reset driver in drivers/reset/reset-socfpga.c.
> 
> > 
> > > 
> > > > 
> > > > Signed-off-by: Ang, Chee Hong 
> > > > ---
> > > >  arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1 +
> > > >  arch/arm/mach-socfpga/spl_s10.c| 4
> > > > 
> > > >  2 files changed, 5 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/mach-
> > > > socfpga/include/mach/reset_manager_s10.h 
> > > > b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > index e186296..3ac46c3 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
> > > >  #define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
> > > >  #define RSTMGR_SPIM0   RSTMGR_DEFINE(1, 17)
> > > >  #define RSTMGR_SPIM1   RSTMGR_DEFINE(1, 18)
> > > > +#define RSTMGR_DMA_OCP RSTMGR_DEFINE(1, 21)
> > > >  #define RSTMGR_L4WD0   RSTMGR_DEFINE(2, 0)
> > > >  #define RSTMGR_L4WD1   RSTMGR_DEFINE(2, 1)
> > > >  #define RSTMGR_L4WD2   RSTMGR_DEFINE(2, 2)
> > > > diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-
> > > > socfpga/spl_s10.c
> > > > index a141ffe..e063229 100644
> > > > --- a/arch/arm/mach-socfpga/spl_s10.c
> > > > +++ b/arch/arm/mach-socfpga/spl_s10.c
> > > > @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
> > > >     writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
> > > > &sysmgr_regs->dma);
> > > >     writel(SYSMGR_DMAPERIPH_ALL_NS, &sysmgr_regs-
> > > > >dma_periph);
> > > >  
> > > > +   /* enable DMA330 DMA */
> > > > +   socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> > > > +   socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
> > > > +
> > > >     spl_disable_firewall_l4_per();
> > > >  
> > > >     spl_disable_firewall_l4_sys();
> > > > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/3] bcm968580xref: remove CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT

[Philippe Reynes]

This board define the flag CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
but it's a mistake. It's a workaround for an issue in nand core.
This issue was fixed by the commit 5f626e78491c ("mtd: nand: raw:
Fix CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT behavior"). Now, this flag
break the nand on this board, so we simply remove it.

Signed-off-by: Philippe Reynes 
---
 include/configs/broadcom_bcm968580xref.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/broadcom_bcm968580xref.h 
b/include/configs/broadcom_bcm968580xref.h
index 52b4f55..fdb6203 100644
--- a/include/configs/broadcom_bcm968580xref.h
+++ b/include/configs/broadcom_bcm968580xref.h
@@ -33,7 +33,6 @@
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_SELF_INIT
 #define CONFIG_SYS_NAND_ONFI_DETECTION
-#define CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
 #endif /* CONFIG_NAND */
 
 /*
-- 
2.7.4

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

[U-Boot] [PATCH 3/3] bcm968380gerg: remove CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT

[Philippe Reynes]

This board define the flag CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
but it's a mistake. It's a workaround for an issue in nand core.
This issue was fixed by the commit 5f626e78491c ("mtd: nand: raw:
Fix CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT behavior"). Now, this flag
break the nand on this board, so we simply remove it.

Signed-off-by: Philippe Reynes 
---
 include/configs/broadcom_bcm968380gerg.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/broadcom_bcm968380gerg.h 
b/include/configs/broadcom_bcm968380gerg.h
index 355f3ef..aa6ce67 100644
--- a/include/configs/broadcom_bcm968380gerg.h
+++ b/include/configs/broadcom_bcm968380gerg.h
@@ -12,5 +12,4 @@
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_SELF_INIT
 #define CONFIG_SYS_NAND_ONFI_DETECTION
-#define CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
 #endif /* CONFIG_NAND */
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

[Michal Simek]

On 03. 05. 19 10:35, Tom Rini wrote:
> On Fri, May 03, 2019 at 09:29:32AM -0700, Michal Simek wrote:
> [snip]
>> I think we need to get more clarity what exactly vxworks expects and
>> what are just your "hacks" to get it work.
>> If vxworks deviates existing dt binding, or create completely new one.
> 
> Hold up.  If it's not in the spec itself (and most stuff is not), the
> Linux bindings are no more authoritative than the BSD ones (which are
> also not, unless things have changed, the Linux ones) than the vxWorks
> ones than anything else.  For a board that is not supported in Linux, I
> don't think it makes sense to treat the primary OS support as something
> that's added to another DT.
> 

This board is using u-boot which is using linux binding. It means this
should be IMHO in separate file from the rest what vxworks expects.
Then we can review u-boot configurations properly.

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

[U-Boot] [PATCH 1/3] watchdog: bcm6345: callback start use tick instead of ms

[Philippe Reynes]

The function bcm6345_wdt_start use the argument timeout
as tick but it should be used as milliseconds.

A clock is added as requirement for this driver.
The frequency of the clock is then used to convert the
millisecond to ticks in the function bcm6345_wdt_start.

Signed-off-by: Philippe Reynes 
---
 drivers/watchdog/bcm6345_wdt.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/bcm6345_wdt.c b/drivers/watchdog/bcm6345_wdt.c
index 44f5662..9f14e7d 100644
--- a/drivers/watchdog/bcm6345_wdt.c
+++ b/drivers/watchdog/bcm6345_wdt.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* WDT Value register */
@@ -26,6 +27,7 @@
 
 struct bcm6345_wdt_priv {
void __iomem *regs;
+   unsigned long clk_rate;
 };
 
 static int bcm6345_wdt_reset(struct udevice *dev)
@@ -41,16 +43,17 @@ static int bcm6345_wdt_reset(struct udevice *dev)
 static int bcm6345_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
 {
struct bcm6345_wdt_priv *priv = dev_get_priv(dev);
+   u32 val = priv->clk_rate / 1000 * timeout;
 
-   if (timeout < WDT_VAL_MIN) {
+   if (val < WDT_VAL_MIN) {
debug("watchdog won't fire with less than 2 ticks\n");
-   timeout = WDT_VAL_MIN;
-   } else if (timeout > WDT_VAL_MAX) {
+   val = WDT_VAL_MIN;
+   } else if (val > WDT_VAL_MAX) {
debug("maximum watchdog timeout exceeded\n");
-   timeout = WDT_VAL_MAX;
+   val = WDT_VAL_MAX;
}
 
-   writel(timeout, priv->regs + WDT_VAL_REG);
+   writel(val, priv->regs + WDT_VAL_REG);
 
return bcm6345_wdt_reset(dev);
 }
@@ -85,11 +88,19 @@ static const struct udevice_id bcm6345_wdt_ids[] = {
 static int bcm6345_wdt_probe(struct udevice *dev)
 {
struct bcm6345_wdt_priv *priv = dev_get_priv(dev);
+   struct clk clk;
+   int ret;
 
priv->regs = dev_remap_addr(dev);
if (!priv->regs)
return -EINVAL;
 
+   ret = clk_get_by_index(dev, 0, &clk);
+   if (!ret)
+   priv->clk_rate = clk_get_rate(&clk);
+   else
+   return -EINVAL;
+
bcm6345_wdt_stop(dev);
 
return 0;
-- 
2.7.4

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

[U-Boot] [PATCH 2/3] dt: bcm6858: watchdog should use a 50Mhz clock

[Philippe Reynes]

The watchdog should use a clock at 50 Mhz, so
instead of using the clock osc (200 Mhz), we
define a reference clock at 50Mhz and use it
for both watchdog.

Signed-off-by: Philippe Reynes 
---
 arch/arm/dts/bcm6858.dtsi | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/bcm6858.dtsi b/arch/arm/dts/bcm6858.dtsi
index 76ba0ea..91f7787 100644
--- a/arch/arm/dts/bcm6858.dtsi
+++ b/arch/arm/dts/bcm6858.dtsi
@@ -66,6 +66,12 @@
clock-frequency = <2>;
u-boot,dm-pre-reloc;
};
+
+   refclk50mhz: refclk50mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   };
};
 
ubus {
@@ -92,13 +98,13 @@
wdt1: watchdog@ff802780 {
compatible = "brcm,bcm6345-wdt";
reg = <0x0 0xff802780 0x0 0x14>;
-   clocks = <&periph_osc>;
+   clocks = <&refclk50mhz>;
};
 
wdt2: watchdog@ff8027c0 {
compatible = "brcm,bcm6345-wdt";
reg = <0x0 0xff8027c0 0x0 0x14>;
-   clocks = <&periph_osc>;
+   clocks = <&refclk50mhz>;
};
 
wdt-reboot {
-- 
2.7.4

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

[U-Boot] [PATCH 0/3] fix bcm6345 watchdog on broadcom board

[Philippe Reynes]

Since the commit: commit 06985289d452 ("watchdog: Implement generic
watchdog_reset() version"), the watchdog is always started and a default
timeout of 6 ms is used. But the driver for the bcm6345 watchdog use
this timeout in ms as tick. So a board using this driver reboot
immediately.

The first commit in this serie fix the driver of the bcm6345 watchdog by
converting the timeout in ms to tick before writing the register. The two
others commits fix the clock used by boards bcm96858xref and bcm963158.

This serie was tested on:
- bcm6838 (mips)
- bcm96858xref (arm) 
- bcm963158 (arm)

Philippe Reynes (3):
  watchdog: bcm6345: callback start use tick instead of ms
  dt: bcm6858: watchdog should use a 50Mhz clock
  dt: bcm63158: watchdog should use a 50Mhz clock

 arch/arm/dts/bcm63158.dtsi | 10 --
 arch/arm/dts/bcm6858.dtsi  | 10 --
 drivers/watchdog/bcm6345_wdt.c | 21 -
 3 files changed, 32 insertions(+), 9 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH 3/3] dt: bcm63158: watchdog should use a 50Mhz clock

[Philippe Reynes]

The watchdog should use a clock at 50 Mhz, so
instead of using the clock osc (200 Mhz), we
define a reference clock at 50Mhz and use it
for both watchdog.

Signed-off-by: Philippe Reynes 
---
 arch/arm/dts/bcm63158.dtsi | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/bcm63158.dtsi b/arch/arm/dts/bcm63158.dtsi
index 4b2eaee..175af38 100644
--- a/arch/arm/dts/bcm63158.dtsi
+++ b/arch/arm/dts/bcm63158.dtsi
@@ -66,6 +66,12 @@
clock-frequency = <0xbebc200>;
u-boot,dm-pre-reloc;
};
+
+   refclk50mhz: refclk50mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   };
};
 
ubus {
@@ -92,13 +98,13 @@
wdt1: watchdog@ff800480 {
compatible = "brcm,bcm6345-wdt";
reg = <0x0 0xff800480 0x0 0x14>;
-   clocks = <&periph_osc>;
+   clocks = <&refclk50mhz>;
};
 
wdt2: watchdog@ff8004c0 {
compatible = "brcm,bcm6345-wdt";
reg = <0x0 0xff8004c0 0x0 0x14>;
-   clocks = <&periph_osc>;
+   clocks = <&refclk50mhz>;
};
 
wdt-reboot {
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

[Tom Rini]

On Fri, May 03, 2019 at 01:35:11PM -0400, Tom Rini wrote:
> On Fri, May 03, 2019 at 09:29:32AM -0700, Michal Simek wrote:
> [snip]
> > I think we need to get more clarity what exactly vxworks expects and
> > what are just your "hacks" to get it work.
> > If vxworks deviates existing dt binding, or create completely new one.
> 
> Hold up.  If it's not in the spec itself (and most stuff is not), the
> Linux bindings are no more authoritative than the BSD ones (which are
> also not, unless things have changed, the Linux ones) than the vxWorks
> ones than anything else.  For a board that is not supported in Linux, I
> don't think it makes sense to treat the primary OS support as something
> that's added to another DT.

And in yet another case of "check, then send, NOT send, then check", I
see FreeBSD has changed.  vxWorks however has not it would seem.

-- 
Tom


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

Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

[Tom Rini]

On Fri, May 03, 2019 at 09:29:32AM -0700, Michal Simek wrote:
[snip]
> I think we need to get more clarity what exactly vxworks expects and
> what are just your "hacks" to get it work.
> If vxworks deviates existing dt binding, or create completely new one.

Hold up.  If it's not in the spec itself (and most stuff is not), the
Linux bindings are no more authoritative than the BSD ones (which are
also not, unless things have changed, the Linux ones) than the vxWorks
ones than anything else.  For a board that is not supported in Linux, I
don't think it makes sense to treat the primary OS support as something
that's added to another DT.

-- 
Tom


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

Re: [U-Boot] [PATCH v2] imx: Use a convenient default value for SYS_MALLOC_F_LEN

[Joris OFFOUGA]

Hi Fabio,

Tested-by Joris Offouga 

BR,

Joris


Le ven. 3 mai 2019 à 19:20, Pierre-Jean Texier  a
écrit :

> Hi Fabio,
>
> Le 03/05/2019 à 19:05, Fabio Estevam a écrit :
> > Commit 3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to
> > simple-bus driver") causes some i.MX boards that were converted
> > to DM, such as warp7, to fail to boot.
> >
> > As explained by Lukas Auer:
> >
> > "With the patch, U-Boot probes the drivers for devices under simple-bus
> > device tree nodes in the pre-relocation device model. The default value
> > of CONFIG_SYS_MALLOC_F_LEN (0x400) leaves U-Boot with not enough memory
> to
> > do this, causing it to hang."
> >
> > Fix this problem by providing a convenient default value for
> > CONFIG_SYS_MALLOC_F_LEN.
> >
> > Reported-by: Pierre-Jean Texier 
> > Suggested-by: Lukas Auer 
> > Signed-off-by: Fabio Estevam 
> > ---
> > Changes since v1:
> > - Move the default setting to the main Kconfig and make it depend
> > on i.MX
> >
> >   Kconfig | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/Kconfig b/Kconfig
> > index 7a5491bd67..fd4ff42c17 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -138,6 +138,8 @@ config SYS_MALLOC_F_LEN
> >   depends on SYS_MALLOC_F
> >   default 0x1000 if AM33XX
> >   default 0x2800 if SANDBOX
> > + default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \
> > +ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5)
> >   default 0x400
> >   help
> > Before relocation, memory is very limited on many platforms.
> Still,
>
>
> Tested-by: Pierre-Jean Texier 
>
>
> Thanks
>
> Pierre-Jean
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] imx: Use a convenient default value for SYS_MALLOC_F_LEN

[Joris OFFOUGA]

Hi Fabio

Tested-by Joris Offouga 

BR

Joris

Le ven. 3 mai 2019 à 19:05, Fabio Estevam  a écrit :

> Commit 3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to
> simple-bus driver") causes some i.MX boards that were converted
> to DM, such as warp7, to fail to boot.
>
> As explained by Lukas Auer:
>
> "With the patch, U-Boot probes the drivers for devices under simple-bus
> device tree nodes in the pre-relocation device model. The default value
> of CONFIG_SYS_MALLOC_F_LEN (0x400) leaves U-Boot with not enough memory to
> do this, causing it to hang."
>
> Fix this problem by providing a convenient default value for
> CONFIG_SYS_MALLOC_F_LEN.
>
> Reported-by: Pierre-Jean Texier 
> Suggested-by: Lukas Auer 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v1:
> - Move the default setting to the main Kconfig and make it depend
> on i.MX
>
>  Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Kconfig b/Kconfig
> index 7a5491bd67..fd4ff42c17 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -138,6 +138,8 @@ config SYS_MALLOC_F_LEN
> depends on SYS_MALLOC_F
> default 0x1000 if AM33XX
> default 0x2800 if SANDBOX
> +   default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \
> +  ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5)
> default 0x400
> help
>   Before relocation, memory is very limited on many platforms.
> Still,
> --
> 2.17.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] imx: Use a convenient default value for SYS_MALLOC_F_LEN

[Pierre-Jean Texier]

Hi Fabio,

Le 03/05/2019 à 19:05, Fabio Estevam a écrit :

Commit 3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to
simple-bus driver") causes some i.MX boards that were converted
to DM, such as warp7, to fail to boot.

As explained by Lukas Auer:

"With the patch, U-Boot probes the drivers for devices under simple-bus
device tree nodes in the pre-relocation device model. The default value
of CONFIG_SYS_MALLOC_F_LEN (0x400) leaves U-Boot with not enough memory to
do this, causing it to hang."

Fix this problem by providing a convenient default value for
CONFIG_SYS_MALLOC_F_LEN.

Reported-by: Pierre-Jean Texier 
Suggested-by: Lukas Auer 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Move the default setting to the main Kconfig and make it depend
on i.MX

  Kconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Kconfig b/Kconfig
index 7a5491bd67..fd4ff42c17 100644
--- a/Kconfig
+++ b/Kconfig
@@ -138,6 +138,8 @@ config SYS_MALLOC_F_LEN
depends on SYS_MALLOC_F
default 0x1000 if AM33XX
default 0x2800 if SANDBOX
+   default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \
+  ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5)
default 0x400
help
  Before relocation, memory is very limited on many platforms. Still,



Tested-by: Pierre-Jean Texier 


Thanks

Pierre-Jean

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

Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller

[Marek Vasut]

On 5/3/19 5:53 PM, Ang, Chee Hong wrote:
> On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
>> On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
>>>
>>> From: "Ang, Chee Hong" 
>> Commit message is missing -- why do you need to enable the DMA330 ?
>>
>> Don't you have a reset driver, like A10 and Gen5 ?
> DMA driver for S10 is still missing in u-boot. I need to enable this
> for booting Linux which is required by Linux's DMA driver.
> I will add the reason to enable DMA330 in the commit message.

Can you also answer my question regarding the reset driver ?

>>> Signed-off-by: Ang, Chee Hong 
>>> ---
>>>  arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1 +
>>>  arch/arm/mach-socfpga/spl_s10.c| 4 
>>>  2 files changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h 
>>> b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
>>> index e186296..3ac46c3 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
>>> @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
>>>  #define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
>>>  #define RSTMGR_SPIM0   RSTMGR_DEFINE(1, 17)
>>>  #define RSTMGR_SPIM1   RSTMGR_DEFINE(1, 18)
>>> +#define RSTMGR_DMA_OCP RSTMGR_DEFINE(1, 21)
>>>  #define RSTMGR_L4WD0   RSTMGR_DEFINE(2, 0)
>>>  #define RSTMGR_L4WD1   RSTMGR_DEFINE(2, 1)
>>>  #define RSTMGR_L4WD2   RSTMGR_DEFINE(2, 2)
>>> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-
>>> socfpga/spl_s10.c
>>> index a141ffe..e063229 100644
>>> --- a/arch/arm/mach-socfpga/spl_s10.c
>>> +++ b/arch/arm/mach-socfpga/spl_s10.c
>>> @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
>>>     writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
>>> &sysmgr_regs->dma);
>>>     writel(SYSMGR_DMAPERIPH_ALL_NS, &sysmgr_regs->dma_periph);
>>>  
>>> +   /* enable DMA330 DMA */
>>> +   socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
>>> +   socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
>>> +
>>>     spl_disable_firewall_l4_per();
>>>  
>>>     spl_disable_firewall_l4_sys();
>>>


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

[U-Boot] [PATCH v2] imx: Use a convenient default value for SYS_MALLOC_F_LEN

[Fabio Estevam]

Commit 3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to
simple-bus driver") causes some i.MX boards that were converted
to DM, such as warp7, to fail to boot.

As explained by Lukas Auer:

"With the patch, U-Boot probes the drivers for devices under simple-bus
device tree nodes in the pre-relocation device model. The default value
of CONFIG_SYS_MALLOC_F_LEN (0x400) leaves U-Boot with not enough memory to
do this, causing it to hang."

Fix this problem by providing a convenient default value for
CONFIG_SYS_MALLOC_F_LEN.

Reported-by: Pierre-Jean Texier 
Suggested-by: Lukas Auer 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Move the default setting to the main Kconfig and make it depend
on i.MX

 Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Kconfig b/Kconfig
index 7a5491bd67..fd4ff42c17 100644
--- a/Kconfig
+++ b/Kconfig
@@ -138,6 +138,8 @@ config SYS_MALLOC_F_LEN
depends on SYS_MALLOC_F
default 0x1000 if AM33XX
default 0x2800 if SANDBOX
+   default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \
+  ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5)
default 0x400
help
  Before relocation, memory is very limited on many platforms. Still,
-- 
2.17.1

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

Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

[Michal Simek]

On 03. 05. 19 6:18, Tom Rini wrote:
> On Fri, May 03, 2019 at 01:34:24PM +0200, Hannes Schmelzer wrote:
>>
>>
>> On 5/2/19 9:03 PM, Tom Rini wrote:
>>> On Thu, May 02, 2019 at 08:34:32PM +0200, Hannes Schmelzer wrote:
 On 5/2/19 6:06 PM, Michal Simek wrote:
> Hi,
 Hi Michal,
> On 02. 05. 19 5:14, Hannes Schmelzer wrote:
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index dfa5b02..2b00129 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -208,6 +208,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
>>  zynq-zc770-xm011-x16.dtb \
>>  zynq-zc770-xm012.dtb \
>>  zynq-zc770-xm013.dtb \
>> +zynq-brsmarc2.dtb \
>> +zynq-brsmarc2_r512.dtb \
> Can't you detect it if you have 512M version?
> u-boot itself has code for these kind of detection.
>
> long get_ram_size(long *base, long maxsize)
 I actually think not,
 because i need different ps7_init stuff for the two different RAM chips.
 (timing, adress lines, ...) But i will check if i even can drop the two
 different dts files.
>> +/ {
>> +model = "BRSMARC2 Zynq SoM";
>> +compatible = "xlnx,zynq-7000";
>> +
>> +fset: factory-settings {
>> +bl-version  = "";
>> +order-no= "";
>> +cpu-order-no= "";
>> +hw-revision = "";
>> +serial-no   = <0>;
>> +device-id   = <0x0>;
>> +parent-id   = <0x0>;
>> +hw-variant  = <0x0>;
>> +hw-platform = <0x0>;
>> +fram-offset = <0x0>;
>> +fram-size   = <0x0>;
>> +cache-disable   = <0x0>;
>> +cpu-clock   = <0x0>;
>> +};
> What's this? No compatible string. This looks quite hacky.
 This are factory settings, used by the OS (in this case vxWorks),
 to identify on which hardware it runs, and have per device unique stuff
 (serial number).
 But you're right, it would be nice to have here some compatible string,
 i will change this. Today we just search for the node "factory-setting".
 A more comfortable ways would be vxFdtNodeOffsetByCompatible()
>> +
>> +aliases {
>> +ethernet0 = &gem0;
>> +ethernet1 = &gem1;
>> +i2c0 = &i2c0;
>> +serial0 = &uart0;
>> +spi0 = &qspi;
>> +mmc0 = &sdhci0;
>> +fset = &fset;
>> +can0 = &can0;
>> +can1 = &can1;
>> +};
>> +
>> +memory {
>> +device_type = "memory";
>> +reg = <0x0 0x1000>;
>> +};
>> +
>> +board {
>> +status = "okay";
>> +compatible = "bur,brsmarc2-som";
>> +usb0mux-gpios = <&gpio0 68 GPIO_ACTIVE_HIGH>;
>> +usb1mux-gpios = <&gpio0 69 GPIO_ACTIVE_HIGH>;
>> +powerdown-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
>> +reset-gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
>> +};
> Where is mainline dt binding for this?
 Nowhere, because u-boot nor linux does use this,
 this is only for the vxWorks OS.
>>> This is what I kinda figured was the case.  We now have some interesting
>>> times ahead of us as yes, we normally think about DTS reviews in terms
>>> of Linux.  But this is all for a board that uses vxWorks.  Perhaps the
>>> best thing to do here is note (and for all of the other boards too, but
>>> you can wait for general feedback before v3'ing them all) in the dts
>>> comment that it's for vxWorks as people tend to assume a DTS file is for
>>> Linux (even with many counter examples).
>> OK. Thanks.
>>
>> would it be fine having it like this ?
>>
>>     /* factory-settings for the vxWorks target */
>>     fset: factory-settings {
>>         compatible = "bur,fsetv1";
>>         bl-version    = "    ";
>>     .
>>    };
>>
>>     /* misc. peripheral, used in vxWorks */
>>     board {
>>         status = "okay";
>>     ...
>>     };
>>
>> Or might be a general description on top would be more helpful?
> 
> I think a general comment at the top saying that this tree is only valid
> for vxWorks and U-Boot is enough detail.

It would be much better to simply put vxworks stuff to one dtsi file and
common stuff to another. That it will be clear what it is vxworks part
and what it is common.


> 
>> In general i pay attention to describe devices as generic as possible,
>> meaning that a) syntax is 

[U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine

[Karsten Merker]

Hello,

I'm currently testing the U-Boot patch for adding booti support
on the RISC-V architecture and the corresponding kernel patch on
a qemu riscv64 "virt" machine with OpenSBI.  While performing the
tests, I have found two probably unrelated issues in U-Boot and
OpenSBI, though I'm unsure whether the actual source of the
problem is on the OpenSBI or on the U-Boot side, therefore I'm
sending this to both the U-Boot and the OpenSBI lists.

a) U-Boot crashes if the system has 2GB of RAM or more and
   uses OpenSBI as the first stage:

-8<--8<--8<--8<--8<--8<-
OpenSBI v0.3 (May  3 2019 16:43:55)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 100 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1-1-gc7ec976ce75 (May 03 2019 - 16:42:32 +0200)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  2 GiB
exception code: 7 , Store/AMO access fault , epc 8020019c , ra 8020a834
### ERROR ### Please RESET the board ###
-8<--8<--8<--8<--8<--8<-

With 1.9GB or less, the combination of U-Boot and OpenSBI works
and successfully boots a Linux system:

-8<--8<--8<--8<--8<--8<-
OpenSBI v0.3 (May  3 2019 16:43:55)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 100 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1-1-gc7ec976ce75 (May 03 2019 - 16:42:32 +0200)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  1.9 GiB
In:uart@1000
Out:   uart@1000
Err:   uart@1000
Net:   
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot:  0 

Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
... is now current device
Scanning virtio 0:1...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8210
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (0 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8100
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=> load virtio 0:1 ${kernel_addr_r} /boot/Image
8949964 bytes read in 4 ms (2.1 GiB/s)
=> booti ${kernel_addr_r} - ${fdtcontroladdr}
## Flattened Device Tree blob at f91353d0
   Booting using the fdt blob at 0xf91353d0
   Using Device Tree in place at f91353d0, end f9138d9c

Starting kernel ...

[0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
[0.00] Linux version 5.1.0-rc7-1-g988141059a7b (build@localhost) 
(gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Fri May 3 16:36:57 CEST 2019
[0.00] initrd not found or empty - disabling initrd
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x8020-0xffff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8020-0xffff]
[0.00] Initmem setup node 0 [mem 0x8020-0xffff]
[0.00] software IO TLB: mapped [mem 0xf3693000-0xf7693000] (64MB)
[0.00] elf_hwcap is 0x112d
[0.00] percpu: Embedded 17 pages/cpu s29592 r8192 d31848 u69632
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 490759
[0.00] Kernel command line: console=ttyS0 rw root=/dev/vda1
[0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 1885148K/1990248K available (5585K kernel code, 353K 
rwdata, 1

Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y

[Eugeniu Rosca]

On Thu, May 02, 2019 at 12:32:53AM +0200, Eugeniu Rosca wrote:
> Hi Tom,
> 
> On Wed, May 01, 2019 at 03:51:49PM -0400, Tom Rini wrote:
> [..]
> > 
> > Agreed, this patch sounds like it addresses a number of problems today
> > that are real problems (I await someone filing a CVE now for our PRNG
> > problem)
> 
> A new CVE has been submitted via https://cveform.mitre.org/.
> Will keep this thread posted with any updates from the CVE Team.

The CVE has been published as:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11690
https://nvd.nist.gov/vuln/detail/CVE-2019-11690

It looks like it is still WIP.

> 
> > and can be iteratively improved on, once merged rather than
> > having a fundamental problem that needs to be addressed.
> > 
> > -- 
> > Tom
> 
> --
> Best regards,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller

[Ang, Chee Hong]

On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
> On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
> > 
> > From: "Ang, Chee Hong" 
> Commit message is missing -- why do you need to enable the DMA330 ?
> 
> Don't you have a reset driver, like A10 and Gen5 ?
DMA driver for S10 is still missing in u-boot. I need to enable this
for booting Linux which is required by Linux's DMA driver.
I will add the reason to enable DMA330 in the commit message.
> 
> > 
> > Signed-off-by: Ang, Chee Hong 
> > ---
> >  arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1 +
> >  arch/arm/mach-socfpga/spl_s10.c| 4 
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h 
> > b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > index e186296..3ac46c3 100644
> > --- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
> >  #define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
> >  #define RSTMGR_SPIM0   RSTMGR_DEFINE(1, 17)
> >  #define RSTMGR_SPIM1   RSTMGR_DEFINE(1, 18)
> > +#define RSTMGR_DMA_OCP RSTMGR_DEFINE(1, 21)
> >  #define RSTMGR_L4WD0   RSTMGR_DEFINE(2, 0)
> >  #define RSTMGR_L4WD1   RSTMGR_DEFINE(2, 1)
> >  #define RSTMGR_L4WD2   RSTMGR_DEFINE(2, 2)
> > diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-
> > socfpga/spl_s10.c
> > index a141ffe..e063229 100644
> > --- a/arch/arm/mach-socfpga/spl_s10.c
> > +++ b/arch/arm/mach-socfpga/spl_s10.c
> > @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
> >     writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
> > &sysmgr_regs->dma);
> >     writel(SYSMGR_DMAPERIPH_ALL_NS, &sysmgr_regs->dma_periph);
> >  
> > +   /* enable DMA330 DMA */
> > +   socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> > +   socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
> > +
> >     spl_disable_firewall_l4_per();
> >  
> >     spl_disable_firewall_l4_sys();
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit b4ee6daad7a2604ca9466b2ba48de86cc27d381f:

  Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx
(2019-05-01 07:25:51 -0400)

are available in the Git repository at:

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

for you to fetch changes up to ff83e4c368f0155617e813d275d88192f05131e1:

  ARM: davinci: Remove unused functions from header (2019-05-03 17:14:49
+0200)


Adam Ford (2):
  usb: ohci: Re-enable commented out delay
  ARM: davinci: Remove unused functions from header

 arch/arm/mach-davinci/include/mach/da8xx-usb.h | 3 ---
 drivers/usb/host/ohci-hcd.c| 2 --
 2 files changed, 5 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/3] Move Stratix 10 SDRAM driver to DM

[Marek Vasut]

On 5/3/19 8:27 AM, Ley Foon Tan wrote:
> Compile ALTERA_SDRAM driver in SPL only and move Stratix 10 SDRAM driver to 
> DM.
> 
> v3 -> v4:
> - Add CONFIG_SPL_ALTERA_SDRAM to config_whitelist.txt in patch [1/3] and 
> remove it in patch [3/3]
> - Remove _remove().
> - Update commit message in patch [2/3]
> 
> v2->v3:
> ---
> - Compile ALTERA_SDRAM driver in SPL only
> - Separate dts change to new patch
> - Change to use #if CONFIG_IS_ENABLED(ALTERA_SDRAM)
> - Add _remove()
> - Remove #ifdef CONFIG_SPL_BUILD checking in sdram_s10.c
> 
> History:
> 
> [v1]: https://patchwork.ozlabs.org/patch/1066765/
> [v2]: https://patchwork.ozlabs.org/patch/1089957/
> [v3]: https://patchwork.ozlabs.org/cover/1093091/
> 
> Ley Foon Tan (3):
>   ddr: altera: Compile ALTERA SDRAM in SPL only
>   arm: dts: Stratix10: Add SDRAM node
>   arm: socfpga: Move Stratix 10 SDRAM driver to DM
> 
>  Makefile  |   2 +-
>  arch/arm/dts/socfpga_stratix10.dtsi   |   9 +
>  arch/arm/mach-socfpga/Kconfig |   4 +-
>  arch/arm/mach-socfpga/spl_s10.c   |  16 +-
>  configs/socfpga_stratix10_defconfig   |   1 +
>  drivers/Makefile  |   2 +-
>  drivers/ddr/altera/Kconfig|  11 +-
>  drivers/ddr/altera/Makefile   |   2 +-
>  drivers/ddr/altera/sdram_s10.c| 243 --
>  .../mach => drivers/ddr/altera}/sdram_s10.h   |   4 -
>  include/configs/socfpga_stratix10_socdk.h |   5 -
>  11 files changed, 200 insertions(+), 99 deletions(-)
>  rename {arch/arm/mach-socfpga/include/mach => 
> drivers/ddr/altera}/sdram_s10.h (97%)
> 
I wanted to pick them, but they don't apply to u-boot/master ?

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