Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
Hi Bin > Hi Rick, > > On Thu, May 28, 2020 at 4:17 PM Rick Chen wrote: > > > > Hi Bin > > > > > From: Bin Meng [mailto:bmeng...@gmail.com] > > > Sent: Wednesday, May 20, 2020 3:40 PM > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List > > > Cc: Bin Meng > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default > > > > > > From: Bin Meng > > > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the > > > reserved memory node for PMP protected memory regions. All RISC-V boards > > > needs to copy the reserved memory node from the device tree provided by > > > the firmware to the device tree used by U-Boot. > > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default. > > > > > > Signed-off-by: Bin Meng > > > --- > > > > > > arch/riscv/Kconfig | 3 +++ > > > configs/sifive_fu540_defconfig | 1 - > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > > > fb5fe5a..5176b35 100644 > > > --- a/arch/riscv/Kconfig > > > +++ b/arch/riscv/Kconfig > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT > > > int > > > default 14 > > > > > > +config OF_BOARD_FIXUP > > > + default y > > > > I think it shall invoke by individual board, just like the description > > of riscv_fdt_copy_resv_mem_node function. > > I believe we should turn on this feature by default for every RISC-V > board, because SBI firmware used memory must be marked as reserved > otherwise OS might use it and get crashed. For boards which don't want > to enable this, they can unset the option in their board defconfig > files. This is to reduce some maintenance effort. But not all RISC-V boards need this configuration. If we enable it by default, non spl configuration will run this fdt fix flow, but it is unnecessary. Thanks, Rick > > > > > In [PATCH 1/2] if source and destination are the same place, it represent > > that > > OF_BOARD_FIXUP is unnecessary. > > > > BTW when I try OF_SEPARATE and OF_BOARD_FIXUP both are enabled, it hit > > the problem as below: > > > > U-Boot SPL 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800) > > Trying to boot from RAM > > > > > > U-Boot 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800) > > > > DRAM: 1 GiB > > failed to add reserved memory: -3 > > -3 means FDT_ERR_NOSPACE. > > The FDT does not have enough space to add reserved memory node. Could > you please check your FDT blob? > > > failed to fixup DT for reserved memory: -3 > > initcall sequence 01253c20 failed at call 0120b8e0 (err=-3) > > ### ERROR ### Please RESET the board ### > > > > I will dig in and figure out what is going on here ? > > Maybe there exist a potential issue somehow! > > > > Regards, > Bin
Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
Hi Bin > Hi Rick, > > On Thu, May 28, 2020 at 4:24 PM Bin Meng wrote: > > > > Hi Rick, > > > > On Thu, May 28, 2020 at 4:17 PM Rick Chen wrote: > > > > > > Hi Bin > > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com] > > > > Sent: Wednesday, May 20, 2020 3:40 PM > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List > > > > Cc: Bin Meng > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default > > > > > > > > From: Bin Meng > > > > > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the > > > > reserved memory node for PMP protected memory regions. All RISC-V > > > > boards needs to copy the reserved memory node from the device tree > > > > provided by the firmware to the device tree used by U-Boot. > > > > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default. > > > > > > > > Signed-off-by: Bin Meng > > > > --- > > > > > > > > arch/riscv/Kconfig | 3 +++ > > > > configs/sifive_fu540_defconfig | 1 - > > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > > > > fb5fe5a..5176b35 100644 > > > > --- a/arch/riscv/Kconfig > > > > +++ b/arch/riscv/Kconfig > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT > > > > int > > > > default 14 > > > > > > > > +config OF_BOARD_FIXUP > > > > + default y > > > > > > I think it shall invoke by individual board, just like the description > > > of riscv_fdt_copy_resv_mem_node function. > > > > I believe we should turn on this feature by default for every RISC-V > > board, because SBI firmware used memory must be marked as reserved > > otherwise OS might use it and get crashed. For boards which don't want > > to enable this, they can unset the option in their board defconfig > > files. This is to reduce some maintenance effort. > > > > > > > > In [PATCH 1/2] if source and destination are the same place, it represent > > > that > > > OF_BOARD_FIXUP is unnecessary. > > > > > > BTW when I try OF_SEPARATE and OF_BOARD_FIXUP both are enabled, it hit > > > the problem as below: > > > > > > U-Boot SPL 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800) > > > Trying to boot from RAM > > > > > > > > > U-Boot 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800) > > > > > > DRAM: 1 GiB > > > failed to add reserved memory: -3 > > > > -3 means FDT_ERR_NOSPACE. > > > > The FDT does not have enough space to add reserved memory node. Could > > you please check your FDT blob? > > > > > failed to fixup DT for reserved memory: -3 > > > initcall sequence 01253c20 failed at call 0120b8e0 > > > (err=-3) > > > ### ERROR ### Please RESET the board ### > > > > > > I will dig in and figure out what is going on here ? > > > Maybe there exist a potential issue somehow! > > Could you please try this patch? > http://patchwork.ozlabs.org/project/uboot/patch/1590655604-13704-2-git-send-email-bmeng...@gmail.com/ I try this patch, it still fail. But after increase 32 more larger, it can pass. Thanks, Rick > > Regards, > Bin
Re: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of CONFIG_SBI_V01
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, May 27, 2020 5:05 PM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Atish Patra; Bin Meng
> Subject: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of
> CONFIG_SBI_V01
>
> From: Bin Meng
>
> sbi_probe_extension() is an API defined in SBI v0.2, not v0.1.
>
> Fixes 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
> Signed-off-by: Bin Meng
> ---
Reviewed-by: Rick Chen
>
> arch/riscv/lib/sbi.c | 37 +++--
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index
> f298846..8fbc238 100644
> --- a/arch/riscv/lib/sbi.c
> +++ b/arch/riscv/lib/sbi.c
> @@ -53,6 +53,25 @@ void sbi_set_timer(uint64_t stime_value) #endif }
>
> +/**
> + * sbi_probe_extension() - Check if an SBI extension ID is supported or not.
> + * @extid: The extension ID to be probed.
> + *
> + * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> + */
> +int sbi_probe_extension(int extid)
> +{
> + struct sbiret ret;
> +
> + ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> + 0, 0, 0, 0, 0);
> + if (!ret.error)
> + if (ret.value)
> + return ret.value;
> +
> + return -ENOTSUPP;
> +}
> +
> #ifdef CONFIG_SBI_V01
>
> /**
> @@ -162,22 +181,4 @@ void sbi_remote_sfence_vma_asid(const unsigned long
> *hart_mask,
> (unsigned long)hart_mask, start, size, asid, 0, 0); }
>
> -/**
> - * sbi_probe_extension() - Check if an SBI extension ID is supported or not.
> - * @extid: The extension ID to be probed.
> - *
> - * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> - */
> -int sbi_probe_extension(int extid)
> -{
> - struct sbiret ret;
> -
> - ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> - 0, 0, 0, 0, 0);
> - if (!ret.error)
> - if (ret.value)
> - return ret.value;
> -
> - return -ENOTSUPP;
> -}
> #endif /* CONFIG_SBI_V01 */
> --
> 2.7.4
>
Re: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version
Hi Bin
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, May 27, 2020 5:05 PM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Atish Patra; Bin Meng
> Subject: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version
>
> From: Bin Meng
>
> U-Boot defaults to use SBI v0.2. Howerver there is a global variable
> sbi_spec_version that stills refers to v0.1. Since it is not used anywhere,
> let's remove it.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/riscv/include/asm/sbi.h | 2 --
> arch/riscv/lib/sbi.c | 3 ---
> 2 files changed, 5 deletions(-)
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 453cb5c..08e1ac0 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -77,7 +77,6 @@ enum sbi_ext_rfence_fid {
> #define SBI_FID_REMOTE_SFENCE_VMA_ASID SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID
> #endif
>
> -#define SBI_SPEC_VERSION_DEFAULT 0x1
> #define SBI_SPEC_VERSION_MAJOR_SHIFT 24
> #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
> #define SBI_SPEC_VERSION_MINOR_MASK0xff
> @@ -90,7 +89,6 @@ enum sbi_ext_rfence_fid {
> #define SBI_ERR_DENIED -4
> #define SBI_ERR_INVALID_ADDRESS-5
>
> -extern unsigned long sbi_spec_version;
> struct sbiret {
> long error;
> long value;
> diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index
> 993597e..f298846 100644
> --- a/arch/riscv/lib/sbi.c
> +++ b/arch/riscv/lib/sbi.c
> @@ -11,9 +11,6 @@
> #include
> #include
>
> -/* default SBI version is 0.1 */
> -unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;
Why not keep this variable and get version of openSbi automatically,
then register v01 or v02 callback function just like sbi_init() of
Atish' patch.
Thanks,
Rick
> -
> struct sbiret sbi_ecall(int ext, int fid, unsigned long arg0,
> unsigned long arg1, unsigned long arg2,
> unsigned long arg3, unsigned long arg4,
> --
> 2.7.4
>
Re: U-Boot mainline: Digilent Zybo-Z7 support
On 01. 06. 20 8:59, Johannes Krottmayer wrote: > Okay, thanks for the fast reply! > > At the time I wrote this mail, I didn't read the docs. > > Off-topic: > > Are there plans for U-Boot to create a default image (including > FSBL, bitstream and U-Boot)? > > For example (additional build step): > $ export BITSTREAM=/path/to/fpga.bit > > For now I use Vivado to create the bitstream file, Vitis for the > FSBL and then bootgen to create the SD card image. SPL is community effort and not supported flow by Xilinx. If you want to use it, use it but don't expect any help from Xilinx to help you with issues. I take care about it, use it but there is no planning behind. I am fixing issues for me and for the rest please send a patch and I will take a look. As far as I know JTAG, SD and qspi(but limited) flows should work. I use SD boot most of the time. If you want to pack bitstream to u-boot.img/itb then it should be quite easy to do and all things are in place. Using FSBL as the part of open source flow. I don't think this is going to happen because mainline u-boot is using mkimage for boot.bin generation and fsbl requires more partitions in boot.bin which is not supported. Definitely patches welcome. Thanks, Michal
Re: [PATCH 3/3] x86: quark: acpi: Replace _ADR() by _UID() in description of PCI host bridge
On Sun, May 31, 2020 at 09:15:15PM -0700, Bin Meng wrote:
> PCI Firmware specification requires _UID() and doesn't require _ADR()
> to be set. Replace latter by former. This fixes the following warning
> reported by ACPICA 20200430:
>
> Warning 3073 - Multiple types (Device object requires either a _HID
> or _ADR, but not both)
>
For all three:
Reviewed-by: Andy Shevchenko
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/include/asm/arch-quark/acpi/southcluster.asl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/arch-quark/acpi/southcluster.asl
> b/arch/x86/include/asm/arch-quark/acpi/southcluster.asl
> index fe9edc1..384dab2 100644
> --- a/arch/x86/include/asm/arch-quark/acpi/southcluster.asl
> +++ b/arch/x86/include/asm/arch-quark/acpi/southcluster.asl
> @@ -8,7 +8,7 @@ Device (PCI0)
> Name(_HID, EISAID("PNP0A08")) /* PCIe */
> Name(_CID, EISAID("PNP0A03")) /* PCI */
>
> - Name(_ADR, 0)
> + Name(_UID, 0)
> Name(_BBN, 0)
>
> Name(MCRS, ResourceTemplate()
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
[PATCH u-boot] eth/r8152: update the firmware
Update the firmware to improve compatibility for none-intel USB
host controller.
Signed-off-by: Hayes Wang
---
drivers/usb/eth/r8152.h| 8 +
drivers/usb/eth/r8152_fw.c | 481 -
2 files changed, 265 insertions(+), 224 deletions(-)
diff --git a/drivers/usb/eth/r8152.h b/drivers/usb/eth/r8152.h
index c7f62b8b3e..10e0da8eb1 100644
--- a/drivers/usb/eth/r8152.h
+++ b/drivers/usb/eth/r8152.h
@@ -25,6 +25,7 @@
#define PLA_BDC_CR 0xd1a0
#define PLA_TEREDO_TIMER 0xd2cc
#define PLA_REALWOW_TIMER 0xd2e8
+#define PLA_EXTRA_STATUS 0xd398
#define PLA_LEDSEL 0xdd90
#define PLA_LED_FEATURE0xdd92
#define PLA_PHYAR 0xde00
@@ -76,6 +77,7 @@
#define USB_DEV_STAT 0xb808
#define USB_CONNECT_TIMER 0xcbf8
#define USB_BURST_SIZE 0xcfc0
+#define USB_FW_FIX_EN1 0xcfcc
#define USB_USB_CTRL 0xd406
#define USB_PHY_CTRL 0xd408
#define USB_TX_AGG 0xd40a
@@ -285,6 +287,9 @@
/* PLA_BOOT_CTRL */
#define AUTOLOAD_DONE 0x0002
+/* PLA_EXTRA_STATUS */
+#define U3P3_CHECK_EN BIT(7)
+
/* USB_USB2PHY */
#define USB2PHY_SUSPEND0x0001
#define USB2PHY_L1 0x0002
@@ -304,6 +309,9 @@
#define STAT_SPEED_HIGH0x
#define STAT_SPEED_FULL0x0002
+/* USB_FW_FIX_EN1 */
+#define FW_IP_RESET_EN BIT(9)
+
/* USB_TX_AGG */
#define TX_AGG_MAX_THRESHOLD 0x03
diff --git a/drivers/usb/eth/r8152_fw.c b/drivers/usb/eth/r8152_fw.c
index 3ebbd533cc..f953b0384b 100644
--- a/drivers/usb/eth/r8152_fw.c
+++ b/drivers/usb/eth/r8152_fw.c
@@ -293,7 +293,7 @@ static u8 r8152b_pla_patch_a2[] = {
0x00, 0xbe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
static u16 r8152b_pla_patch_a2_bp[] = {
- 0xfc28, 0x8000, 0xfc28, 0x17a5, 0xfc2a, 0x13ad,
+ 0xfc26, 0x8000, 0xfc28, 0x17a5, 0xfc2a, 0x13ad,
0xfc2c, 0x184d, 0xfc2e, 0x01e1 };
static u16 r8153_ram_code_a[] = {
@@ -321,181 +321,150 @@ static u16 r8153_ram_code_a[] = {
0xB438, 0x3591, 0xB436, 0xB820, 0xB438, 0x0210 };
static u8 r8153_usb_patch_c[] = {
- 0x08, 0xe0, 0x0a, 0xe0, 0x14, 0xe0, 0x2e, 0xe0,
- 0x37, 0xe0, 0x3e, 0xe0, 0x6d, 0xe0, 0x78, 0xe0,
+ 0x08, 0xe0, 0x0a, 0xe0, 0x14, 0xe0, 0x58, 0xe0,
+ 0x64, 0xe0, 0x79, 0xe0, 0xab, 0xe0, 0xb6, 0xe0,
0x02, 0xc5, 0x00, 0xbd, 0x38, 0x3b, 0xdb, 0x49,
0x04, 0xf1, 0x06, 0xc3, 0x00, 0xbb, 0x5a, 0x02,
0x05, 0xc4, 0x03, 0xc3, 0x00, 0xbb, 0xa4, 0x04,
- 0x7e, 0x02, 0x30, 0xd4, 0x30, 0x18, 0x18, 0xc1,
- 0x0c, 0xe8, 0x17, 0xc6, 0xc7, 0x65, 0xd0, 0x49,
+ 0x7e, 0x02, 0x30, 0xd4, 0x65, 0xc6, 0x66, 0x61,
+ 0x92, 0x49, 0x12, 0xf1, 0x3e, 0xc0, 0x02, 0x61,
+ 0x97, 0x49, 0x05, 0xf0, 0x3c, 0xc0, 0x00, 0x61,
+ 0x90, 0x49, 0x0a, 0xf1, 0xca, 0x63, 0xb0, 0x49,
+ 0x09, 0xf1, 0xb1, 0x49, 0x05, 0xf0, 0x32, 0xc0,
+ 0x00, 0x71, 0x9e, 0x49, 0x03, 0xf1, 0xb0, 0x48,
+ 0x05, 0xe0, 0x30, 0x48, 0xda, 0x61, 0x10, 0x48,
+ 0xda, 0x89, 0x4a, 0xc6, 0xc0, 0x60, 0x85, 0x49,
+ 0x03, 0xf0, 0x31, 0x48, 0x04, 0xe0, 0xb1, 0x48,
+ 0xb2, 0x48, 0x0f, 0xe0, 0x30, 0x18, 0x1b, 0xc1,
+ 0x0f, 0xe8, 0x1a, 0xc6, 0xc7, 0x65, 0xd0, 0x49,
0x05, 0xf0, 0x32, 0x48, 0x02, 0xc2, 0x00, 0xba,
0x3e, 0x16, 0x02, 0xc2, 0x00, 0xba, 0x48, 0x16,
- 0x02, 0xb4, 0x09, 0xc2, 0x40, 0x99, 0x0e, 0x48,
- 0x42, 0x98, 0x42, 0x70, 0x8e, 0x49, 0xfe, 0xf1,
- 0x02, 0xb0, 0x80, 0xff, 0xc0, 0xd4, 0xe4, 0x40,
- 0x20, 0xd4, 0xb0, 0x49, 0x04, 0xf0, 0x30, 0x18,
- 0x06, 0xc1, 0xef, 0xef, 0xfa, 0xc7, 0x02, 0xc0,
- 0x00, 0xb8, 0xd0, 0x10, 0xe4, 0x4b, 0x07, 0xc3,
- 0x70, 0x61, 0x12, 0x48, 0x70, 0x89, 0x02, 0xc3,
- 0x00, 0xbb, 0x9c, 0x15, 0x20, 0xd4, 0x2b, 0xc5,
- 0xa0, 0x77, 0x00, 0x1c, 0xa0, 0x9c, 0x28, 0xc5,
- 0xa0, 0x64, 0xc0, 0x48, 0xc1, 0x48, 0xc2, 0x48,
- 0xa0, 0x8c, 0xb1, 0x64, 0xc0, 0x48, 0xb1, 0x8c,
- 0x20, 0xc5, 0xa0, 0x64, 0x40, 0x48, 0x41, 0x48,
- 0xc2, 0x48, 0xa0, 0x8c, 0x19, 0xc5, 0xa4, 0x64,
- 0x44, 0x48, 0xa4, 0x8c, 0xb1, 0x64, 0x40, 0x48,
- 0xb1, 0x8c, 0x14, 0xc4, 0x80, 0x73, 0x13, 0xc4,
- 0x82, 0x9b, 0x11, 0x1b, 0x80, 0x9b, 0x0c, 0xc5,
- 0xa0, 0x64, 0x40, 0x48, 0x41, 0x48, 0x42, 0x48,
- 0xa0, 0x8c, 0x05, 0xc5, 0xa0, 0x9f, 0x02, 0xc5,
- 0x00, 0xbd, 0x6c, 0x3a, 0x1e, 0xfc, 0x10, 0xd8,
- 0x86, 0xd4, 0xf8, 0xcb, 0x20, 0xe4, 0x0a, 0xc0,
- 0x16, 0x61, 0x91, 0x48, 0x16, 0x89, 0x07, 0xc0,
- 0x11, 0x19, 0x0c, 0x89, 0x02, 0xc1, 0x00, 0xb9,
- 0x02, 0x06, 0x00, 0xd4, 0x40, 0xb4, 0xfe, 0xc0,
- 0x16, 0x61, 0x91, 0x48, 0x16, 0x89, 0xfb, 0xc0,
- 0x11, 0x19, 0x0c, 0x89, 0x02, 0xc1, 0x00, 0xb9,
- 0xd2, 0x05, 0x00, 0x00 };
+ 0x02, 0xc2, 0x00, 0xba, 0x4a, 0x16, 0x02, 0xb4,
+ 0x09, 0xc2, 0x40, 0x99, 0x0e, 0x48, 0x42, 0x98,
+ 0x42, 0x70, 0x8e, 0x49, 0xfe
Re: [PATCHv5][1/2] rockchip: rk3328: add rock-pi-e dts file
On 2020/6/1 上午12:01, b.l.huang wrote:
The ROCK-PI-E is a credit card size SBC based on Rockchip RK3328
Quad-Core ARM Cortex A53.
Net - Dual ethernet port, 1 X Gbe, 1 X 100M
USB - USB 3.0
DC - USB-Type C, 5V 2A
Storage - TF card, eMMC
Just build idbloader.img and u-boot.itb for Rockpi E board and
follow the blow steps to replace the relevant partition.
dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc
dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc
Signed-off-by: Banglang Huang
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes for v5
- Update the board information to
doc/board/rockchip/rockchip.rst
Changes for v4
- separate dts file to another commit
- fix bootup on tpl / spl mode
Changes for v3
- rename to rock-pi-e
Changes for v2
- add introduction for rockpie in doc/README.rockchip
- enable CONFIG_MISC_INIT_R, CONFIG_SMBIOS_MANUFACTURER,
and CONFIG_SMBIOS_PRODUCT_NAME
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 33 +++
arch/arm/dts/rk3328-rock-pi-e.dts | 267 ++
3 files changed, 302 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3328-rock-pi-e.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 12ec6c71dc..67d1adea2d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -107,7 +107,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
rk3328-roc-cc.dtb \
- rk3328-rock64.dtb
+ rk3328-rock64.dtb \
+ rk3328-rock-pi-e.dtb
dtb-$(CONFIG_ROCKCHIP_RK3368) += \
rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
new file mode 100644
index 00..bf5b1f3adc
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr3-666.dtsi"
+
+&gpio0 {
+ u-boot,dm-spl;
+};
+
+&pinctrl {
+ u-boot,dm-spl;
+};
+
+&sdmmc0m1_gpio {
+ u-boot,dm-spl;
+};
+
+&pcfg_pull_up_4ma {
+ u-boot,dm-spl;
+};
+
+&usb_host0_xhci {
+ vbus-supply = <&vcc5v0_host_xhci>;
+ status = "okay";
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+&vcc_sd {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3328-rock-pi-e.dts
b/arch/arm/dts/rk3328-rock-pi-e.dts
new file mode 100644
index 00..21656b64a2
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e.dts
@@ -0,0 +1,267 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+ model = "Radxa Rockpi E";
+ compatible = "radxa,rock-pi-e", "rockchip,rk3328";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ gmac_clkin: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_clkin";
+ #clock-cells = <0>;
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0m1_gpio>;
+ regulator-name = "vcc_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <&vcc_io>;
+ };
+
+ vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ regulator-name = "vcc5v0_host_xhci";
+ gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&emmc {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ supports-emmc;
+ disable-wp;
+ non-removable;
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_bus8>;
+ vmmc-supply = <&vcc_io>;
+ vqmmc-supply = <&vcc18_emmc>;
+ status = "okay";
+};
+
+&gmac2io {
+ assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
+ assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
+ clock_in_out = "input";
+ phy-suppl
Re: [PATCHv5][2/2] rockchip: rk3328: add rock-pi-e-rk3328_defconfig file
On 2020/6/1 上午12:02, b.l.huang wrote: This commit add the default configuration file and relevant description for rock-pi-e board Signed-off-by: Banglang Huang Reviewed-by: Kever Yang Thanks, - Kever --- board/rockchip/evb_rk3328/MAINTAINERS | 7 ++ configs/rock-pi-e-rk3328_defconfig| 104 ++ doc/board/rockchip/rockchip.rst | 1 + 3 files changed, 112 insertions(+) create mode 100644 configs/rock-pi-e-rk3328_defconfig diff --git a/board/rockchip/evb_rk3328/MAINTAINERS b/board/rockchip/evb_rk3328/MAINTAINERS index 89becf41c5..e7dd59ff4e 100644 --- a/board/rockchip/evb_rk3328/MAINTAINERS +++ b/board/rockchip/evb_rk3328/MAINTAINERS @@ -17,3 +17,10 @@ M: Matwey V. Kornilov S: Maintained F: configs/rock64-rk3328_defconfig F: arch/arm/dts/rk3328-rock64-u-boot.dtsi + +ROCKPIE-RK3328 +M: Banglang Huang +S: Maintained +F: configs/rock-pi-e-rk3328_defconfig +F: arch/arm/dts/rk3328-rock-pi-e.dts +F: arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi diff --git a/configs/rock-pi-e-rk3328_defconfig b/configs/rock-pi-e-rk3328_defconfig new file mode 100644 index 00..759838775f --- /dev/null +++ b/configs/rock-pi-e-rk3328_defconfig @@ -0,0 +1,104 @@ +CONFIG_ARM=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_GPIO_SUPPORT=y +CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_ROCKCHIP_RK3328=y +CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y +CONFIG_TPL_LIBCOMMON_SUPPORT=y +CONFIG_TPL_LIBGENERIC_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_SPL_STACK_R_ADDR=0x400 +CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_DEBUG_UART_BASE=0xFF13 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_SMBIOS_PRODUCT_NAME="rock-pi-e_rk3328" +CONFIG_DEBUG_UART=y +CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 +# CONFIG_ANDROID_BOOT_IMAGE is not set +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock-pi-e.dtb" +CONFIG_MISC_INIT_R=y +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_TPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_I2C_SUPPORT=y +CONFIG_SPL_POWER_SUPPORT=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_TPL_DRIVERS_MISC_SUPPORT=y +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_GPT=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_TIME=y +CONFIG_SPL_OF_CONTROL=y +CONFIG_TPL_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock-pi-e" +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_TPL_OF_PLATDATA=y +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_TPL_DM=y +CONFIG_REGMAP=y +CONFIG_SPL_REGMAP=y +CONFIG_TPL_REGMAP=y +CONFIG_SYSCON=y +CONFIG_SPL_SYSCON=y +CONFIG_TPL_SYSCON=y +CONFIG_CLK=y +CONFIG_SPL_CLK=y +CONFIG_FASTBOOT_BUF_ADDR=0x800800 +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_ROCKCHIP_GPIO=y +CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SF_DEFAULT_SPEED=2000 +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY=y +CONFIG_PINCTRL=y +CONFIG_SPL_PINCTRL=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_RK8XX=y +CONFIG_SPL_DM_REGULATOR=y +CONFIG_REGULATOR_PWM=y +CONFIG_SPL_DM_REGULATOR_FIXED=y +CONFIG_DM_REGULATOR_FIXED=y +CONFIG_REGULATOR_RK8XX=y +CONFIG_PWM_ROCKCHIP=y +CONFIG_RAM=y +CONFIG_SPL_RAM=y +CONFIG_TPL_RAM=y +CONFIG_DM_RESET=y +CONFIG_BAUDRATE=150 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_DEBUG_UART_ANNOUNCE=y +CONFIG_DEBUG_UART_SKIP_INIT=y +CONFIG_SYSRESET=y +# CONFIG_TPL_SYSRESET is not set +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y +CONFIG_USB_DWC2=y +CONFIG_USB_DWC3=y +# CONFIG_USB_DWC3_GADGET is not set +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_SPL_TINY_MEMSET=y +CONFIG_TPL_TINY_MEMSET=y +CONFIG_ERRNO_STR=y +CONFIG_SMBIOS_MANUFACTURER="radxa" diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index 7b72fab496..e7dee7d0ac 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -48,6 +48,7 @@ List of mainline supported rockchip boards: - Rockchip Evb-RK3328 (evb-rk3328) - Pine64 Rock64 (rock64-rk3328) - Firefly-RK3328 (roc-cc-rk3328) + - Radxa Rockpi E (rock-pi-e-rk3328) * rk3368 - GeekBox (geekbox) - PX5 EVB (evb-px5)
Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
Hi Rick, On Mon, Jun 1, 2020 at 3:36 PM Rick Chen wrote: > > Hi Bin > > > Hi Rick, > > > > On Thu, May 28, 2020 at 4:17 PM Rick Chen wrote: > > > > > > Hi Bin > > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com] > > > > Sent: Wednesday, May 20, 2020 3:40 PM > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List > > > > Cc: Bin Meng > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default > > > > > > > > From: Bin Meng > > > > > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the > > > > reserved memory node for PMP protected memory regions. All RISC-V > > > > boards needs to copy the reserved memory node from the device tree > > > > provided by the firmware to the device tree used by U-Boot. > > > > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default. > > > > > > > > Signed-off-by: Bin Meng > > > > --- > > > > > > > > arch/riscv/Kconfig | 3 +++ > > > > configs/sifive_fu540_defconfig | 1 - > > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > > > > fb5fe5a..5176b35 100644 > > > > --- a/arch/riscv/Kconfig > > > > +++ b/arch/riscv/Kconfig > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT > > > > int > > > > default 14 > > > > > > > > +config OF_BOARD_FIXUP > > > > + default y > > > > > > I think it shall invoke by individual board, just like the description > > > of riscv_fdt_copy_resv_mem_node function. > > > > I believe we should turn on this feature by default for every RISC-V > > board, because SBI firmware used memory must be marked as reserved > > otherwise OS might use it and get crashed. For boards which don't want > > to enable this, they can unset the option in their board defconfig > > files. This is to reduce some maintenance effort. > > But not all RISC-V boards need this configuration. > If we enable it by default, non spl configuration will run this fdt > fix flow, but it is unnecessary. > Non SPL configuration also needs this, because U-Boot has to patch the final DTB that is passed to the kernel. It's a RISC-V architecture thing. Regards, Bin
Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
Hi Rick, On Mon, Jun 1, 2020 at 3:40 PM Rick Chen wrote: > > Hi Bin > > > Hi Rick, > > > > On Thu, May 28, 2020 at 4:24 PM Bin Meng wrote: > > > > > > Hi Rick, > > > > > > On Thu, May 28, 2020 at 4:17 PM Rick Chen wrote: > > > > > > > > Hi Bin > > > > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com] > > > > > Sent: Wednesday, May 20, 2020 3:40 PM > > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List > > > > > Cc: Bin Meng > > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default > > > > > > > > > > From: Bin Meng > > > > > > > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the > > > > > reserved memory node for PMP protected memory regions. All RISC-V > > > > > boards needs to copy the reserved memory node from the device tree > > > > > provided by the firmware to the device tree used by U-Boot. > > > > > > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default. > > > > > > > > > > Signed-off-by: Bin Meng > > > > > --- > > > > > > > > > > arch/riscv/Kconfig | 3 +++ > > > > > configs/sifive_fu540_defconfig | 1 - > > > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > > > > > fb5fe5a..5176b35 100644 > > > > > --- a/arch/riscv/Kconfig > > > > > +++ b/arch/riscv/Kconfig > > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT > > > > > int > > > > > default 14 > > > > > > > > > > +config OF_BOARD_FIXUP > > > > > + default y > > > > > > > > I think it shall invoke by individual board, just like the description > > > > of riscv_fdt_copy_resv_mem_node function. > > > > > > I believe we should turn on this feature by default for every RISC-V > > > board, because SBI firmware used memory must be marked as reserved > > > otherwise OS might use it and get crashed. For boards which don't want > > > to enable this, they can unset the option in their board defconfig > > > files. This is to reduce some maintenance effort. > > > > > > > > > > > In [PATCH 1/2] if source and destination are the same place, it > > > > represent that > > > > OF_BOARD_FIXUP is unnecessary. > > > > > > > > BTW when I try OF_SEPARATE and OF_BOARD_FIXUP both are enabled, it hit > > > > the problem as below: > > > > > > > > U-Boot SPL 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 > > > > +0800) > > > > Trying to boot from RAM > > > > > > > > > > > > U-Boot 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800) > > > > > > > > DRAM: 1 GiB > > > > failed to add reserved memory: -3 > > > > > > -3 means FDT_ERR_NOSPACE. > > > > > > The FDT does not have enough space to add reserved memory node. Could > > > you please check your FDT blob? > > > > > > > failed to fixup DT for reserved memory: -3 > > > > initcall sequence 01253c20 failed at call 0120b8e0 > > > > (err=-3) > > > > ### ERROR ### Please RESET the board ### > > > > > > > > I will dig in and figure out what is going on here ? > > > > Maybe there exist a potential issue somehow! > > > > Could you please try this patch? > > http://patchwork.ozlabs.org/project/uboot/patch/1590655604-13704-2-git-send-email-bmeng...@gmail.com/ > > I try this patch, it still fail. > But after increase 32 more larger, it can pass. > What number did you enlarge this fdt size to? Regards, Bin
Re: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version
Hi Rick,
On Mon, Jun 1, 2020 at 4:14 PM Rick Chen wrote:
>
> Hi Bin
>
> > From: Bin Meng [mailto:bmeng...@gmail.com]
> > Sent: Wednesday, May 27, 2020 5:05 PM
> > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > Cc: Atish Patra; Bin Meng
> > Subject: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version
> >
> > From: Bin Meng
> >
> > U-Boot defaults to use SBI v0.2. Howerver there is a global variable
> > sbi_spec_version that stills refers to v0.1. Since it is not used anywhere,
> > let's remove it.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > arch/riscv/include/asm/sbi.h | 2 --
> > arch/riscv/lib/sbi.c | 3 ---
> > 2 files changed, 5 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > index 453cb5c..08e1ac0 100644
> > --- a/arch/riscv/include/asm/sbi.h
> > +++ b/arch/riscv/include/asm/sbi.h
> > @@ -77,7 +77,6 @@ enum sbi_ext_rfence_fid {
> > #define SBI_FID_REMOTE_SFENCE_VMA_ASID
> > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID
> > #endif
> >
> > -#define SBI_SPEC_VERSION_DEFAULT 0x1
> > #define SBI_SPEC_VERSION_MAJOR_SHIFT 24
> > #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
> > #define SBI_SPEC_VERSION_MINOR_MASK0xff
> > @@ -90,7 +89,6 @@ enum sbi_ext_rfence_fid {
> > #define SBI_ERR_DENIED -4
> > #define SBI_ERR_INVALID_ADDRESS-5
> >
> > -extern unsigned long sbi_spec_version;
> > struct sbiret {
> > long error;
> > long value;
> > diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index
> > 993597e..f298846 100644
> > --- a/arch/riscv/lib/sbi.c
> > +++ b/arch/riscv/lib/sbi.c
> > @@ -11,9 +11,6 @@
> > #include
> > #include
> >
> > -/* default SBI version is 0.1 */
> > -unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;
>
> Why not keep this variable and get version of openSbi automatically,
> then register v01 or v02 callback function just like sbi_init() of
> Atish' patch.
I feel this is not needed anyway, because we are using Kconfig option
to pass the same information.
Regards,
Bin
Re: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of CONFIG_SBI_V01
Hi Bin
> > From: Bin Meng [mailto:bmeng...@gmail.com]
> > Sent: Wednesday, May 27, 2020 5:05 PM
> > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > Cc: Atish Patra; Bin Meng
> > Subject: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of
> > CONFIG_SBI_V01
> >
> > From: Bin Meng
> >
> > sbi_probe_extension() is an API defined in SBI v0.2, not v0.1.
> >
> > Fixes 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
> > Signed-off-by: Bin Meng
> > ---
>
> Reviewed-by: Rick Chen
>
BTW, it seem look like sbi_remote_fence_i, sbi_remote_sfence_vma and
sbi_remote_sfence_vma_asid
are all can be used no mater in SBI_V01 or SBI_V02. Because you have
distinguished them in sbi.h
Thanks,
Rick
> >
> > arch/riscv/lib/sbi.c | 37 +++--
> > 1 file changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index
> > f298846..8fbc238 100644
> > --- a/arch/riscv/lib/sbi.c
> > +++ b/arch/riscv/lib/sbi.c
> > @@ -53,6 +53,25 @@ void sbi_set_timer(uint64_t stime_value) #endif }
> >
> > +/**
> > + * sbi_probe_extension() - Check if an SBI extension ID is supported or
> > not.
> > + * @extid: The extension ID to be probed.
> > + *
> > + * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> > + */
> > +int sbi_probe_extension(int extid)
> > +{
> > + struct sbiret ret;
> > +
> > + ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> > + 0, 0, 0, 0, 0);
> > + if (!ret.error)
> > + if (ret.value)
> > + return ret.value;
> > +
> > + return -ENOTSUPP;
> > +}
> > +
> > #ifdef CONFIG_SBI_V01
> >
> > /**
> > @@ -162,22 +181,4 @@ void sbi_remote_sfence_vma_asid(const unsigned long
> > *hart_mask,
> > (unsigned long)hart_mask, start, size, asid, 0, 0); }
> >
> > -/**
> > - * sbi_probe_extension() - Check if an SBI extension ID is supported or
> > not.
> > - * @extid: The extension ID to be probed.
> > - *
> > - * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> > - */
> > -int sbi_probe_extension(int extid)
> > -{
> > - struct sbiret ret;
> > -
> > - ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> > - 0, 0, 0, 0, 0);
> > - if (!ret.error)
> > - if (ret.value)
> > - return ret.value;
> > -
> > - return -ENOTSUPP;
> > -}
> > #endif /* CONFIG_SBI_V01 */
> > --
> > 2.7.4
> >
Re: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of CONFIG_SBI_V01
Hi Rick,
On Mon, Jun 1, 2020 at 5:08 PM Rick Chen wrote:
>
> Hi Bin
>
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Wednesday, May 27, 2020 5:05 PM
> > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > Cc: Atish Patra; Bin Meng
> > > Subject: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of
> > > CONFIG_SBI_V01
> > >
> > > From: Bin Meng
> > >
> > > sbi_probe_extension() is an API defined in SBI v0.2, not v0.1.
> > >
> > > Fixes 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
> > > Signed-off-by: Bin Meng
> > > ---
> >
> > Reviewed-by: Rick Chen
> >
>
> BTW, it seem look like sbi_remote_fence_i, sbi_remote_sfence_vma and
> sbi_remote_sfence_vma_asid
> are all can be used no mater in SBI_V01 or SBI_V02. Because you have
> distinguished them in sbi.h
No these calls are different and not compatible between SBI_V01 and SBI_V02.
See commit 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
Regards,
Bin
Re: [PATCH v3] spl: allow board_spl_fit_post_load() to fail
On 6/1/20 4:30 AM, Peng Fan wrote: >> Subject: [PATCH v3] spl: allow board_spl_fit_post_load() to fail >> >> On i.MX platforms board_spl_fit_post_load() can check the loaded SPL image >> for authenticity using its HAB engine. U-Boot's SPL mechanism allows >> booting images from other sources as well, but in the current setup the SPL >> would just hang if it encounters an image that does not pass scrutiny. > > security. > >> Allowing the function to return an error, allows the SPL to try booting from >> another source as a fallback instead of ending up as a brick. > > This will break secure boot chain. How? Please elaborate. jump_to_image_no_args() will authenticate the image before starting it, so I don't think so. However, that is still prone to time-of-check/time-of-use attack anyway.
[PATCH] cmd: part: Add 'block' sub-command
From: Razvan Becheriu
Add part block sub-command which returns block size.
e.g.:
part block mmc $mmcdev system_a system_a_index
Signed-off-by: Razvan Becheriu
---
cmd/part.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/cmd/part.c b/cmd/part.c
index 5e4e45ca6d..d78d914e7a 100644
--- a/cmd/part.c
+++ b/cmd/part.c
@@ -25,6 +25,7 @@
enum cmd_part_info {
CMD_PART_INFO_START = 0,
CMD_PART_INFO_SIZE,
+ CMD_PART_INFO_BLOCK,
CMD_PART_INFO_NUMBER
};
@@ -151,6 +152,9 @@ static int do_part_info(int argc, char * const argv[], enum
cmd_part_info param)
case CMD_PART_INFO_SIZE:
snprintf(buf, sizeof(buf), LBAF, info.size);
break;
+ case CMD_PART_INFO_BLOCK:
+ snprintf(buf, sizeof(buf), LBAF, info.blksz);
+ break;
case CMD_PART_INFO_NUMBER:
snprintf(buf, sizeof(buf), "0x%x", part);
break;
@@ -177,6 +181,11 @@ static int do_part_size(int argc, char * const argv[])
return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
}
+static int do_part_block(int argc, char * const argv[])
+{
+ return do_part_info(argc, argv, CMD_PART_INFO_BLOCK);
+}
+
static int do_part_number(int argc, char * const argv[])
{
return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
@@ -195,6 +204,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return do_part_start(argc - 2, argv + 2);
else if (!strcmp(argv[1], "size"))
return do_part_size(argc - 2, argv + 2);
+ else if (!strcmp(argv[1], "block"))
+ return do_part_block(argc - 2, argv + 2);
else if (!strcmp(argv[1], "number"))
return do_part_number(argc - 2, argv + 2);
@@ -219,6 +230,9 @@ U_BOOT_CMD(
"part size\n"
"- set environment variable to the size of the partition (in
blocks)\n"
" part can be either partition number or partition name\n"
+ "part block\n"
+ "- set environment variable to the size of the partition block\n"
+ " part can be either partition number or partition name\n"
"part number\n"
"- set environment variable to the partition number using the
partition name\n"
" part must be specified as partition name"
--
2.25.1
[PATCH]: cmd: part: add part block command
The Intel Edison OTA process requires a conversion of data size from bytes to number of blocks. The following functions are used: # function ota_conv_sizes # Convert a bytes size to a block size # input bytesize : size in bytes to convert # input blksize : size of a block in bytes # output num_blk : converted size in blocks # function ota_mmc_write # Write a memory buffer to mmc drive # input floadaddr: address of buffer to write # input u_part_start : block start in mmc # input num_blk : number of block to write This patch adds the cmd part sub-command 'block' which returns the partition block size in bytes.
Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote: > Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be > loaded explicitly. Earlier versions didn't need that as they where using > an EEPROM for that purpose. This series takes care of setting up the > relevant infrastructure and run the firmware loading routine at the > right moment. > > Note that this builds on top of Sylwester Nawrocki's "USB host support > for Raspberry Pi 4 board" series. > > --- Please don't forget about this series. The new 8GB RPi4 contains this HW design change and USB will not work without it. See this discussion on the downstream kernel github, where other OS/bootloaders are hitting the issue: https://github.com/raspberrypi/firmware/issues/1402 Otherwise, the Linux version of this is already in linux-next: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote: > On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote: >> Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be >> loaded explicitly. Earlier versions didn't need that as they where using >> an EEPROM for that purpose. This series takes care of setting up the >> relevant infrastructure and run the firmware loading routine at the >> right moment. >> >> Note that this builds on top of Sylwester Nawrocki's "USB host support >> for Raspberry Pi 4 board" series. >> >> --- > > Please don't forget about this series. The new 8GB RPi4 contains this HW > design > change and USB will not work without it. See this discussion on the downstream > kernel github, where other OS/bootloaders are hitting the issue: > > https://github.com/raspberrypi/firmware/issues/1402 > > Otherwise, the Linux version of this is already in linux-next: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc We're already at 2020.07-rc3 , so unless this is a bugfix (does not look that way), this will have to wait for next release cycle. Also, it seems there was a lengthy ongoing discussion, is that already sorted out ?
Re: [PATCH] power: pmic: Add SPL Kconfig entry for PFUZE100
On 5/30/20 2:22 AM, Marek Vasut wrote: > Add Kconfig entry for the PFUZE PMIC, SPL variant. > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Jaehoon Chung > Cc: Peng Fan > Cc: Stefano Babic Reviewed-by: Jaehoon Chung > --- > drivers/power/pmic/Kconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig > index ef8bf49d49..a62aa38054 100644 > --- a/drivers/power/pmic/Kconfig > +++ b/drivers/power/pmic/Kconfig > @@ -105,6 +105,13 @@ config DM_PMIC_PFUZE100 > This config enables implementation of driver-model pmic uclass features > for PMIC PFUZE100. The driver implements read/write operations. > > +config SPL_DM_PMIC_PFUZE100 > + bool "Enable Driver Model for PMIC PFUZE100 in SPL" > + depends on DM_PMIC > + ---help--- > + This config enables implementation of driver-model pmic uclass features > + for PMIC PFUZE100 in SPL. The driver implements read/write operations. > + > config DM_PMIC_MAX77686 > bool "Enable Driver Model for PMIC MAX77686" > depends on DM_PMIC >
Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote: > On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote: > > On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote: > > > Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be > > > loaded explicitly. Earlier versions didn't need that as they where using > > > an EEPROM for that purpose. This series takes care of setting up the > > > relevant infrastructure and run the firmware loading routine at the > > > right moment. > > > > > > Note that this builds on top of Sylwester Nawrocki's "USB host support > > > for Raspberry Pi 4 board" series. > > > > > > --- > > > > Please don't forget about this series. The new 8GB RPi4 contains this HW > > design > > change and USB will not work without it. See this discussion on the > > downstream > > kernel github, where other OS/bootloaders are hitting the issue: > > > > https://github.com/raspberrypi/firmware/issues/1402 > > > > Otherwise, the Linux version of this is already in linux-next: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc > > We're already at 2020.07-rc3 , so unless this is a bugfix (does not look > that way), this will have to wait for next release cycle. Of course. As long as it eventually gets in I'm happy (not implying this specific series is flawless, but the overall mechanism). I'm just worried this gets lost. > Also, it seems > there was a lengthy ongoing discussion, is that already sorted out ? Well, there was some discussion on how to incorporate the platform specific callback into XCHI's code. Which this revision of the series addresses. But, IIRC, that's pretty much it as far as discussion is concerned. Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 6/1/20 1:09 PM, Nicolas Saenz Julienne wrote: > On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote: >> On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote: >>> On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote: Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be loaded explicitly. Earlier versions didn't need that as they where using an EEPROM for that purpose. This series takes care of setting up the relevant infrastructure and run the firmware loading routine at the right moment. Note that this builds on top of Sylwester Nawrocki's "USB host support for Raspberry Pi 4 board" series. --- >>> >>> Please don't forget about this series. The new 8GB RPi4 contains this HW >>> design >>> change and USB will not work without it. See this discussion on the >>> downstream >>> kernel github, where other OS/bootloaders are hitting the issue: >>> >>> https://github.com/raspberrypi/firmware/issues/1402 >>> >>> Otherwise, the Linux version of this is already in linux-next: >>> >>> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc >> >> We're already at 2020.07-rc3 , so unless this is a bugfix (does not look >> that way), this will have to wait for next release cycle. > > Of course. As long as it eventually gets in I'm happy (not implying this > specific series is flawless, but the overall mechanism). I'm just worried this > gets lost. > >> Also, it seems >> there was a lengthy ongoing discussion, is that already sorted out ? > > Well, there was some discussion on how to incorporate the platform specific > callback into XCHI's code. Which this revision of the series addresses. But, > IIRC, that's pretty much it as far as discussion is concerned. Oh, right, since the firmware loading hook looks like a reset hook, why isn't that implemented via reset controller API instead ?
Re: [PATCH v2 0/2] gpio: Add a managed API
On 31/05/20 08:08AM, Simon Glass wrote: > Hi Pratyush, > > On Fri, 29 May 2020 at 15:39, Pratyush Yadav wrote: > > > > Hi, > > > > This is a re-submission of Jean-Jacques' earlier work in October last > > year. It can be found at [0]. The goal is to facilitate porting drivers > > from the linux kernel. Most of the series will be about adding managed > > API to existing infrastructure (GPIO, reset, regmap (already > > submitted)). > > > > This particular series is about GPIOs. It adds a managed API using the > > API as Linux. To make it 100% compatible with linux, there is a small > > deviation from u-boot's way of naming the gpio lists: the managed > > equivalent of gpio_request_by_name(..,"blabla-gpios", ...) is > > devm_gpiod_get_index(..., "blabla", ...) > > > > Changes in v2: > > - The original series had a patch that checked for NULL pointers in the > > core GPIO functions. The checks were needed because of the addition of > > devm_gpiod_get_index_optional() which would return NULL when when no > > GPIO was assigned to the requested function. This is convenient for > > drivers that need to handle optional GPIOs. > > > > Simon argued that those should be behind a Kconfig option because of > > code size concerns. He also argued against implicit return in the > > macro that checked for the optional GPIOs. > > > > This submission removes the controversial patch so that base > > functionality can get unblocked. > > > > We still need to take a stance on who is responsible for the NULL > > check: the driver or the GPIO core? Do we want to trust drivers to > > take care of the NULL checks, or do we want to distrust them and make > > sure they don't send us anything bogus in the GPIO core. For now the > > responsibility lies on the drivers by default. I will send a separate > > RFC of the NULL check patch and we can probably discuss the issue > > there. > > > > [0] > > https://patchwork.ozlabs.org/project/uboot/cover/20191001115130.18886-1-jjhib...@ti.com/ > > > > Jean-Jacques Hiblot (2): > > drivers: gpio: Add a managed API to get a GPIO from the device-tree > > test: gpio: Add tests for the managed API > > > > arch/sandbox/dts/test.dts | 10 > > drivers/gpio/gpio-uclass.c | 70 + > > include/asm-generic/gpio.h | 47 + > > test/dm/gpio.c | 102 + > > 4 files changed, 229 insertions(+) > > > > -- > > 2.26.2 > > > > The first question I have is why do you want to allocate the gpio_desc > and return it? Doesn't the caller have a place for that in its private > struct? Ask the Linux folks that ;-) The main aim of this series is to make it easier to port and maintain drivers from Linux. The less changes we have to make when porting a driver, the easier it is to port future fixes and features. Linux drivers (like the TI J721E WIZ [0] for which this effort is mainly being made) use these APIs. FWIW, the docs in Linux say the optional wrappers to the functions are added as a convenience for drivers that need to handle optional GPIOs. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/ti/phy-j721e-wiz.c -- Regards, Pratyush Yadav Texas Instruments India
Re: [PATCH 07/24] arm: Remove configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig board
On Mon, Jun 01, 2020 at 05:23:09AM +, Priyanka Jain wrote: > >-Original Message- > >From: Tom Rini > >Sent: Friday, May 29, 2020 1:32 AM > >To: Priyanka Jain > >Cc: Jagan Teki ; Simon Glass > >; u-boot@lists.denx.de; linux- > >amar...@amarulasolutions.com > >Subject: Re: [PATCH 07/24] arm: Remove configs/P1010RDB- > >PA_36BIT_NAND_SECBOOT_defconfig board > > > >On Thu, May 28, 2020 at 07:05:38AM +, Priyanka Jain wrote: > >> >-Original Message- > >> >From: U-Boot On Behalf Of Jagan Teki > >> >Sent: Wednesday, May 27, 2020 10:17 PM > >> >To: Simon Glass ; Tom Rini > >> >Cc: u-boot@lists.denx.de; linux-amar...@amarulasolutions.com; Jagan > >> >Teki > >> >Subject: [PATCH 07/24] arm: Remove configs/P1010RDB- > >> >PA_36BIT_NAND_SECBOOT_defconfig board > >> > > >> >This board has not been converted to CONFIG_DM_SPI by the deadline. > >> > > >> >Remove it. > >> > > >> >Patch-cc: Qiang Zhao > >> >Signed-off-by: Jagan Teki > >> >--- > >> > arch/powerpc/cpu/mpc85xx/Kconfig | 1 - > >> > board/freescale/p1010rdb/Kconfig | 14 - > >> > board/freescale/p1010rdb/MAINTAINERS | 33 - > >> > board/freescale/p1010rdb/Makefile | 24 - > >> > board/freescale/p1010rdb/README.P1010RDB-PA | 208 - > >> > board/freescale/p1010rdb/README.P1010RDB-PB | 188 - > >> > board/freescale/p1010rdb/ddr.c| 235 -- > >> > board/freescale/p1010rdb/law.c| 16 - > >> > board/freescale/p1010rdb/p1010rdb.c | 731 - > >> > board/freescale/p1010rdb/spl.c| 114 --- > >> > board/freescale/p1010rdb/spl_minimal.c| 65 -- > >> > board/freescale/p1010rdb/tlb.c| 90 -- > >> > .../P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 63 -- > >> > configs/P1010RDB-PA_36BIT_NAND_defconfig | 85 -- > >> > .../P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig | 62 -- > >> > configs/P1010RDB-PA_36BIT_NOR_defconfig | 67 -- > >> > configs/P1010RDB-PA_36BIT_SDCARD_defconfig| 79 -- > >> > ...010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig | 64 -- > >> >configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 81 -- > >> > configs/P1010RDB-PA_NAND_SECBOOT_defconfig| 62 -- > >> > configs/P1010RDB-PA_NAND_defconfig| 84 -- > >> > configs/P1010RDB-PA_NOR_SECBOOT_defconfig | 60 -- > >> > configs/P1010RDB-PA_NOR_defconfig | 66 -- > >> > configs/P1010RDB-PA_SDCARD_defconfig | 78 -- > >> > .../P1010RDB-PA_SPIFLASH_SECBOOT_defconfig| 63 -- > >> > configs/P1010RDB-PA_SPIFLASH_defconfig| 80 -- > >> > .../P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig | 63 -- > >> > configs/P1010RDB-PB_36BIT_NAND_defconfig | 85 -- > >> > .../P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig | 62 -- > >> > configs/P1010RDB-PB_36BIT_NOR_defconfig | 67 -- > >> > configs/P1010RDB-PB_36BIT_SDCARD_defconfig| 79 -- > >> > ...010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig | 64 -- > >> >configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 81 -- > >> > configs/P1010RDB-PB_NAND_SECBOOT_defconfig| 62 -- > >> > configs/P1010RDB-PB_NAND_defconfig| 84 -- > >> > configs/P1010RDB-PB_NOR_SECBOOT_defconfig | 61 -- > >> > configs/P1010RDB-PB_NOR_defconfig | 66 -- > >> > configs/P1010RDB-PB_SDCARD_defconfig | 78 -- > >> > .../P1010RDB-PB_SPIFLASH_SECBOOT_defconfig| 63 -- > >> > configs/P1010RDB-PB_SPIFLASH_defconfig| 80 -- > >> > include/configs/P1010RDB.h| 766 -- > >> > 41 files changed, 4474 deletions(-) > >> > delete mode 100644 board/freescale/p1010rdb/Kconfig delete mode > >> >100644 board/freescale/p1010rdb/MAINTAINERS > >> > delete mode 100644 board/freescale/p1010rdb/Makefile delete mode > >> >100644 board/freescale/p1010rdb/README.P1010RDB-PA > >> > delete mode 100644 board/freescale/p1010rdb/README.P1010RDB-PB > >> > delete mode 100644 board/freescale/p1010rdb/ddr.c delete mode > >> >100644 board/freescale/p1010rdb/law.c delete mode 100644 > >> >board/freescale/p1010rdb/p1010rdb.c > >> > delete mode 100644 board/freescale/p1010rdb/spl.c delete mode > >> >100644 board/freescale/p1010rdb/spl_minimal.c > >> > delete mode 100644 board/freescale/p1010rdb/tlb.c delete mode > >> >100644 configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig > >> > delete mode 100644 configs/P1010RDB-PA_36BIT_NAND_defconfig > >> > delete mode 100644 configs/P1010RDB- > >PA_36BIT_NOR_SECBOOT_defconfig > >> > delete mode 100644 configs/P1010RDB-PA_36BIT_NOR_defconfig > >> > delete mode 100644 configs/P1010RDB-PA_36BIT_SDCARD_defconfig > >> > delete mode 100644 configs/P1010RDB- > >> >PA_36BIT_SPIFLASH_SECBOOT_defconfig > >> > delete mode 100644 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig > >> > delete mode 100644 configs/P1010RDB-PA_NAND_SECBOOT_defconfig > >> > delete mode 100644 configs/P1010RDB-PA_NAND_defconfig > >> > delete mode 100644 configs/P1010RDB-PA_NOR_SECBOOT_defconfig > >> > delete mode 1006
Re: [PATCH 1/1] fastboot: add support for 'reboot fastboot' command
On 27.05.20 15:56, Alex Kiernan wrote:
> On Wed, May 27, 2020 at 12:14 PM Roman Kovalivskyi
> wrote:
>> From: Roman Stratiienko
>>
>> Android 10 adds support for dynamic partitions and in order to support
>> them userspace fastboot must be used[1]. New tool fastbootd is
>> included into recovery image.
>>
>> Userspace fastboot works from recovery and is launched if:
>> 1) - Dynamic partitioning is enabled
>> 2) - Boot control block has 'boot-fastboot' value into command field
>> The bootloader is expected to load and boot into the recovery image
>> upon seeing boot-fastboot in the BCB command. Recovery then parses the
>> BCB message and switches to fastbootd mode[2].
>>
>> Please note that boot script is expected to handle 'boot-fastboot'
>> command in BCB and load into recovery mode.
>>
>> Bootloader must support 'reboot fastboot' command which should reboot
>> device into userspace fastboot to accomodate those changes[3].
>>
>> [1] - https://source.android.com/devices/bootloader/fastbootd
>> [2] -
>> https://source.android.com/devices/bootloader/fastbootd#unified_fastboot_and_recovery
>> [3] -
>> https://source.android.com/devices/bootloader/fastbootd#modifications_to_the_bootloader
>>
>> Signed-off-by: Roman Kovalivskyi
>> Signed-off-by: Roman Stratiienko
>> Change-Id: I9d2bdc9a6f6f31ea98572fe155e1cc8341e9af76
>> ---
>> drivers/fastboot/fb_command.c | 42 +
>> drivers/fastboot/fb_common.c| 31
>> drivers/usb/gadget/f_fastboot.c | 2 ++
>> include/fastboot.h | 9 +++
>> 4 files changed, 84 insertions(+)
>>
>> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
>> index 49f6a61c3745..3616133b880e 100644
>> --- a/drivers/fastboot/fb_command.c
>> +++ b/drivers/fastboot/fb_command.c
>> @@ -37,6 +37,8 @@ static void flash(char *, char *);
>> static void erase(char *, char *);
>> #endif
>> static void reboot_bootloader(char *, char *);
>> +static void reboot_fastbootd(char *, char *);
>> +static void reboot_recovery(char *, char *);
>> #if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
>> static void oem_format(char *, char *);
>> #endif
>> @@ -79,6 +81,14 @@ static const struct {
>> .command = "reboot-bootloader",
>> .dispatch = reboot_bootloader
>> },
>> + [FASTBOOT_COMMAND_REBOOT_FASTBOOTD] = {
>> + .command = "reboot-fastboot",
>> + .dispatch = reboot_fastbootd
>> + },
>> + [FASTBOOT_COMMAND_REBOOT_RECOVERY] = {
>> + .command = "reboot-recovery",
>> + .dispatch = reboot_recovery
>> + },
>> [FASTBOOT_COMMAND_SET_ACTIVE] = {
>> .command = "set_active",
>> .dispatch = okay
>> @@ -307,12 +317,44 @@ static void erase(char *cmd_parameter, char *response)
>> */
>> static void reboot_bootloader(char *cmd_parameter, char *response)
>> {
>> +#if CONFIG_IS_ENABLED(CMD_BCB)
>> + if (fastboot_set_flag("bootonce-bootloader"))
>> +#else
>> if (fastboot_set_reboot_flag())
>> +#endif
>> fastboot_fail("Cannot set reboot flag", response);
>> else
>> fastboot_okay(NULL, response);
>> }
>>
>> +/**
>> + * reboot_fastbootd() - Sets reboot fastboot flag.
>> + *
>> + * @cmd_parameter: Pointer to command parameter
>> + * @response: Pointer to fastboot response buffer
>> + */
>> +static void reboot_fastbootd(char *cmd_parameter, char *response)
>> +{
>> + if (fastboot_set_flag("boot-fastboot"))
>> + fastboot_fail("Cannot set fastboot flag", response);
>> + else
>> + fastboot_okay(NULL, response);
>> +}
>> +
>> +/**
>> + * reboot_recovery() - Sets reboot recovery flag.
>> + *
>> + * @cmd_parameter: Pointer to command parameter
>> + * @response: Pointer to fastboot response buffer
>> + */
>> +static void reboot_recovery(char *cmd_parameter, char *response)
>> +{
>> + if (fastboot_set_flag("boot-recovery"))
>> + fastboot_fail("Cannot set recovery flag", response);
>> + else
>> + fastboot_okay(NULL, response);
>> +}
>> +
>> #if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
>> /**
>> * oem_format() - Execute the OEM format command
>> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
>> index c3735a44af74..b6401640ad06 100644
>> --- a/drivers/fastboot/fb_common.c
>> +++ b/drivers/fastboot/fb_common.c
>> @@ -93,6 +93,37 @@ int __weak fastboot_set_reboot_flag(void)
>> return -ENOSYS;
>> }
>>
>> +/**
>> + * fastboot_set_flag() - Set flag to indicate reboot-recovery
>> + *
>> + * Set flag which indicates that we should reboot into the recovery
>> + * following the reboot that fastboot executes after this function.
>> + */
>> +int fastboot_set_flag(const char *command)
>> +{
>> +#if CONFIG_IS_ENABLED(CMD_BCB)
>> + char cmd[32];
>> +
>> + snprintf(cmd, sizeof(cmd), "bcb load %d misc",
>> +
Thoughts on code line length
Hey all, As I see tech sites are noting that Linus has changed the kernel's code style to no longer be so strict about 80 character line width, I figured I should say something here given how much we follow the Linux kernel anyhow. Given that we've long told people to ignore checkpatch for dts files, and to not split error messages anyhow, and that it's more about "does the code read well", I think this is a good change that we'll pick up with our next re-sync of checkpatch.pl. I figured over the weekend I would grab Simon's checkpatch series today, but I'll wait a day or two and sync it to v5.7 release before grabbing. I think this is a good change overall given the amount of times I've had to reduce readability slightly (and use odd variable names) to not exceed 80 characters on a line by just a few. -- Tom signature.asc Description: PGP signature
[PATCH 1/1] smbios: empty strings in smbios_add_string()
smbios_add_string() cannot deal with empty strings. This leads to incorrect
property values and invalid tables. E.g. for the pine64-lts_defconfig
CONFIG_SMBIOS_MANUFACTURER="". Linux command dmidecode shows:
Table 1:
Manufacturer: sunxi
Product Name: sunxi
Table 3:
Invalid entry length (2). DMI table is broken! Stop.
Replace empty strings by "Unknown".
Signed-off-by: Heinrich Schuchardt
---
lib/smbios.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/smbios.c b/lib/smbios.c
index 7b74971f68..a8c8519dcf 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -31,6 +31,8 @@ static int smbios_add_string(char *start, const char *str)
{
int i = 1;
char *p = start;
+ if (!*str)
+ str = "Unknown";
for (;;) {
if (!*p) {
--
2.26.2
[PATCH 1/1] sunxi: Pine64-LTS: SMBIOS properties
Provide accurate values of the manufacturer and the product name. PINE Microsystems Inc. is referred to on https://www.pine64.org/contact/. Signed-off-by: Heinrich Schuchardt --- configs/pine64-lts_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig index ef108a1a31..a8ff34a376 100644 --- a/configs/pine64-lts_defconfig +++ b/configs/pine64-lts_defconfig @@ -8,8 +8,10 @@ CONFIG_DRAM_ZQ=3881949 CONFIG_MMC0_CD_PIN="" CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_SPL_SPI_SUNXI=y +CONFIG_SMBIOS_PRODUCT_NAME="PINE A64-LTS" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-lts" CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y +CONFIG_SMBIOS_MANUFACTURER="PINE Microsystems Inc." -- 2.26.2
Re: U-Boot mainline: Digilent Zybo-Z7 support
On 01.06.20 at 10:18, Michal Simek wrote:
> SPL is community effort and not supported flow by Xilinx. If you want to
> use it, use it but don't expect any help from Xilinx to help you with
> issues. I take care about it, use it but there is no planning behind. I
> am fixing issues for me and for the rest please send a patch and I will
> take a look. As far as I know JTAG, SD and qspi(but limited) flows
> should work. I use SD boot most of the time.
Thanks for the clarification.
> If you want to pack bitstream to u-boot.img/itb then it should be quite
> easy to do and all things are in place.
How is the official U-Boot way, to use the created image on ZYNQ boards
or which generated files must be placed on a SD card? Unfortunately I
couldn't find any information in the docs at this time. I have tried to
create the image with the (custom) bitstream file. Used a FIT source
(based on ) which I have
attached. But I have no idea how place the image on the SD card. Tried a
simple...
$ dd=if=/path/to/U-Boot/u-boot.img of=/dev/sdf
but didn't work. Also tried to rename the image to BOOT.BIN and place it
in the root directory of a FAT32 filesystem.
When I use the Xilinx tools to generate the image with following, it
works:
* Vivado: Create bitstream from design
* Vitis: Create and build FSBL
* Build U-Boot
* Create BIF:
image {
[bootloader]fsbl.elf
fpga.bit
u-boot.elf
}
* Use bootgen to create the image
* Create FAT32 filesystem on SD card
* Place generated image (BOOT.BIN) to root directory
Kind regards,
Johannes K.
// SPDX-License-Identifier: (BSD-2-Clause)
/dts-v1/;
/ {
description = "Configuration to load custom Xilinx FPGA bitstreams";
images {
uboot {
description = "U-Boot (32-bit)";
data = /incbin/("u-boot-nodtb.bin");
type = "firmware";
os = "u-boot";
arch = "arm";
compression = "none";
load = <0x400>;
entry = <0x400>;
hash {
algo = "md5";
};
};
fpga {
description = "Xilinx FPGA Bitstream";
data =
/incbin/("/home/krj/projects/xilinx/ZYBO_Z7/fpga.bit");
type = "fpga";
arch = "arm";
compression = "none";
hash {
algo = "md5";
};
};
fdt_1 {
description = "zynq-zc702";
data = /incbin/("arch/arm/dts/zynq-zybo-z7.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
load = <0x10>;
hash {
algo = "md5";
};
};
};
configurations {
default = "config_1";
};
};
Re: [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC
On 31.05.20 17:34, Heinrich Schuchardt wrote:
> On 5/22/20 8:12 PM, Heinrich Schuchardt wrote:
>> On 5/22/20 5:21 PM, Jan Kiszka wrote:
>>> On 22.05.20 16:55, Heinrich Schuchardt wrote:
On 22.05.20 14:21, Jan Kiszka wrote:
> On 22.05.20 13:38, Heinrich Schuchardt wrote:
>> Am May 22, 2020 10:50:29 AM UTC schrieb Jan Kiszka
>> :
>>> On 22.05.20 12:42, Heinrich Schuchardt wrote:
On 5/20/20 2:22 PM, Tom Rini wrote:
> On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> This driver is safe to use in SPL without relocation. Denying
>> DM_FLAG_PRE_RELOC prevents its usability for verifying the main
>>> U-Boot
>> or other artifacts from the SPL unless needless enabling the full
>>> driver
>> set (SPL_OF_PLATDATA).
>>
>> Fixes: 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
>>> DM_FLAG_PRE_RELOC")
>> CC: Heinrich Schuchardt
>> CC: Marek Vasut
>> Signed-off-by: Jan Kiszka
>
> Applied to u-boot/master, thanks!
>
With this patch applied pine64-lts_defconfig with CONFIG_RSA=y does
>>> not
boot anymore. See the output below. So something is wrong with this
>>> driver.
Do you have an idea how to analyze what is wrong? Unfortunately there
>>> is
no DEBUG_UART available on the Pine A64 LTS board.
>>>
>>> I would start crippling it down until things start to boot again. Are
>>> you using it (for image verification e.g.), or is this just the
>>> registration that breaks already?
>>>
>>
>>
>> RSA is needed in the UEFI subsystem for verifying variables and images.
>> But there is no need in SPL for it at all.
>>
>> In my configuration RSA is not used at all. Something breaks before even
>> the console becomes available.
>>
>> The pine64-lts_defconfig board boots via SPL->BL31->U-Boot
>
> But then a workaround for you would be to turn this driver off in SPL.
> UEFI is main U-Boot only, isn't it?
>
> That said, understanding the reason for the breakage would still be nice
> for the case someone needs to validate what SPL loads with the help of
> RSA (which is the case for us on an AM65x board).
>
> Jan
>
As I described above I did *not* select RSA_SPL. The breakage is in main
U-boot. SPL works fine loading TF-A BL31 which in turn loads U-Boot. But
during driver initialization U-Boot does not even reach the point where
we have a console due to something wrong with DM_FLAG_PRE_RELOC.
>>>
>>> Sorry, missed that detail. But that is indeed weird because - to my
>>> understanding - this driver should be totally passive until someone
>>> calls rsa_mod_exp() (which should only happen late, when UEFI comes into
>>> play).
>>>
>>> Can you validate that this function is not involved by emptying its body?
>>>
>>> Also, until everything is understood, we could limit DM_FLAG_PRE_RELOC
>>> to BUILD_SPL.
>>>
>>> Jan
>>>
>>
>> Disabling the only consumer of UCLASS_MOD_EXP does not help.
>>
>> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
>> index 1d55b997e3..89a08274f2 100644
>> --- a/lib/rsa/rsa-verify.c
>> +++ b/lib/rsa/rsa-verify.c
>> @@ -334,7 +334,8 @@ static int rsa_verify_key(struct image_sign_info *info,
>> hash_len = checksum->checksum_len;
>>
>> #if !defined(USE_HOSTCC)
>> - ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev);
>> + //ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev);
>> + ret = 1;
>>
>> Emptying function mod_exp_sw() does not help.
>>
>> The board boots if I rename the driver:
>>
>> U_BOOT_DRIVER(mod_exp_sw) = {
>> - .name = "mod_exp_sw",
>> + .name = "mod_exp_sw1",
>>
>> So it seems the very act of loading the driver before relocation is
>> enough to cause the problem.
>>
>> To be more specific, if
>>
>> ret = uclass_get(drv->id, &uc);
>>
>> is called in device_bind_common() - drivers/core/device.c for name =
>> "mod_exp_sw" booting fails.
>>
>> This does not boot:
>>
>> ret = uclass_get(drv->id, &uc);
>> + if (!strcmp(name, "mod_exp_sw"))
>> + return -ENOENT;
>>
>> This does boot:
>>
>> + if (!strcmp(name, "mod_exp_sw"))
>> + return -ENOENT;
>> ret = uclass_get(drv->id, &uc);
>>
>> So I tried to look into uclass_get():
>>
>> If
>>
>> uc = calloc(1, sizeof(*uc));
>>
>> is executed in uclass_add() for UCLASS_MOD_EXP booting fails.
>>
>> This does not boot:
>>
>> uc = calloc(1, sizeof(*uc));
>> if (!uc)
>> return -ENOMEM;
>> + if (id == UCLASS_MOD_EXP)
>> + return -ENOENT;
>>
>> This boots:
>>
>> + if (id == UCLASS_MOD_EXP)
>> + return -ENOENT;
>> uc = calloc(1, sizeof(*uc));
>>
>> Enlarging CONFIG_SYS_MALLOC_F_LEN f
Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On Mon, 2020-06-01 at 13:12 +0200, Marek Vasut wrote: > On 6/1/20 1:09 PM, Nicolas Saenz Julienne wrote: > > On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote: > > > On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote: > > > > On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote: > > > > > Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to > > > > > be > > > > > loaded explicitly. Earlier versions didn't need that as they where > > > > > using > > > > > an EEPROM for that purpose. This series takes care of setting up the > > > > > relevant infrastructure and run the firmware loading routine at the > > > > > right moment. > > > > > > > > > > Note that this builds on top of Sylwester Nawrocki's "USB host support > > > > > for Raspberry Pi 4 board" series. > > > > > > > > > > --- > > > > > > > > Please don't forget about this series. The new 8GB RPi4 contains this HW > > > > design > > > > change and USB will not work without it. See this discussion on the > > > > downstream > > > > kernel github, where other OS/bootloaders are hitting the issue: > > > > > > > > https://github.com/raspberrypi/firmware/issues/1402 > > > > > > > > Otherwise, the Linux version of this is already in linux-next: > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc > > > We're already at 2020.07-rc3 , so unless this is a bugfix (does not look > > > that way), this will have to wait for next release cycle. > > > > Of course. As long as it eventually gets in I'm happy (not implying this > > specific series is flawless, but the overall mechanism). I'm just worried > > this > > gets lost. > > > > > Also, it seems > > > there was a lengthy ongoing discussion, is that already sorted out ? > > > > Well, there was some discussion on how to incorporate the platform specific > > callback into XCHI's code. Which this revision of the series addresses. But, > > IIRC, that's pretty much it as far as discussion is concerned. > > Oh, right, since the firmware loading hook looks like a reset hook, why > isn't that implemented via reset controller API instead ? That could be pretty clean, I hadn't though about it that way. Some questions: - Being a PCIe device the XHCI controller doesn't show up in the device-tree. I guess it could be added as a child node of pcie-brcmstb, but is that even acceptable? - Same goes for xhci-pci being a consumer of the reset controller. Given the reset scheme is board specific (the chip can be found all over the place, but the firmware loading scheme is 100% RPi specific), to what extent we can introduce that as a binding? Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/1] sunxi: Pine64-LTS: SMBIOS properties
On 01/06/2020 14:56, Heinrich Schuchardt wrote: > Provide accurate values of the manufacturer and the product name. > > PINE Microsystems Inc. is referred to on https://www.pine64.org/contact/. While this patch looks alright, I wonder if we can just use the "model" property in the DT's root node, at least for the product name? This would not only avoid every defconfig to be touched, but would also cover all other platforms (at least ARM based ones, probably PPC and MIPS as well). The manufacturer is less straight-forward to handle generically, but the string before the comma in the DT root's compatible property should give a hint. The Linux kernel contains a machine readable list of those prefixes: Documentation/devicetree/bindings/vendor-prefixes.yaml So we could pick the vendor at compile time based on that. Of course any config could still overwrite this. Does that make sense? If people agree, I could try to make a patch for that. Cheers, Andre. > > Signed-off-by: Heinrich Schuchardt > --- > configs/pine64-lts_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig > index ef108a1a31..a8ff34a376 100644 > --- a/configs/pine64-lts_defconfig > +++ b/configs/pine64-lts_defconfig > @@ -8,8 +8,10 @@ CONFIG_DRAM_ZQ=3881949 > CONFIG_MMC0_CD_PIN="" > CONFIG_MMC_SUNXI_SLOT_EXTRA=2 > CONFIG_SPL_SPI_SUNXI=y > +CONFIG_SMBIOS_PRODUCT_NAME="PINE A64-LTS" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-lts" > CONFIG_SUN8I_EMAC=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > +CONFIG_SMBIOS_MANUFACTURER="PINE Microsystems Inc." > -- > 2.26.2 >
Re: [PATCH v2 0/2] gpio: Add a managed API
Hi Pratyush, On Mon, 1 Jun 2020 at 05:22, Pratyush Yadav wrote: > > On 31/05/20 08:08AM, Simon Glass wrote: > > Hi Pratyush, > > > > On Fri, 29 May 2020 at 15:39, Pratyush Yadav wrote: > > > > > > Hi, > > > > > > This is a re-submission of Jean-Jacques' earlier work in October last > > > year. It can be found at [0]. The goal is to facilitate porting drivers > > > from the linux kernel. Most of the series will be about adding managed > > > API to existing infrastructure (GPIO, reset, regmap (already > > > submitted)). > > > > > > This particular series is about GPIOs. It adds a managed API using the > > > API as Linux. To make it 100% compatible with linux, there is a small > > > deviation from u-boot's way of naming the gpio lists: the managed > > > equivalent of gpio_request_by_name(..,"blabla-gpios", ...) is > > > devm_gpiod_get_index(..., "blabla", ...) > > > > > > Changes in v2: > > > - The original series had a patch that checked for NULL pointers in the > > > core GPIO functions. The checks were needed because of the addition of > > > devm_gpiod_get_index_optional() which would return NULL when when no > > > GPIO was assigned to the requested function. This is convenient for > > > drivers that need to handle optional GPIOs. > > > > > > Simon argued that those should be behind a Kconfig option because of > > > code size concerns. He also argued against implicit return in the > > > macro that checked for the optional GPIOs. > > > > > > This submission removes the controversial patch so that base > > > functionality can get unblocked. > > > > > > We still need to take a stance on who is responsible for the NULL > > > check: the driver or the GPIO core? Do we want to trust drivers to > > > take care of the NULL checks, or do we want to distrust them and make > > > sure they don't send us anything bogus in the GPIO core. For now the > > > responsibility lies on the drivers by default. I will send a separate > > > RFC of the NULL check patch and we can probably discuss the issue > > > there. > > > > > > [0] > > > https://patchwork.ozlabs.org/project/uboot/cover/20191001115130.18886-1-jjhib...@ti.com/ > > > > > > Jean-Jacques Hiblot (2): > > > drivers: gpio: Add a managed API to get a GPIO from the device-tree > > > test: gpio: Add tests for the managed API > > > > > > arch/sandbox/dts/test.dts | 10 > > > drivers/gpio/gpio-uclass.c | 70 + > > > include/asm-generic/gpio.h | 47 + > > > test/dm/gpio.c | 102 + > > > 4 files changed, 229 insertions(+) > > > > > > -- > > > 2.26.2 > > > > > > > The first question I have is why do you want to allocate the gpio_desc > > and return it? Doesn't the caller have a place for that in its private > > struct? > > Ask the Linux folks that ;-) > > The main aim of this series is to make it easier to port and maintain > drivers from Linux. The less changes we have to make when porting a > driver, the easier it is to port future fixes and features. > > Linux drivers (like the TI J721E WIZ [0] for which this effort is mainly > being made) use these APIs. FWIW, the docs in Linux say the optional > wrappers to the functions are added as a convenience for drivers that > need to handle optional GPIOs. U-Boot already supports optional GPIOs. Can we put this behind a CONFIG_LINUX_COMPAT_GPIO flag perhaps, so people know they are trading off code / memory size for compatibility? > > [0] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/ti/phy-j721e-wiz.c > > -- > Regards, > Pratyush Yadav > Texas Instruments India Regards, Simon
[GIT PULL] rpi: second round for v2020.07
Hi Tom, Please take into account this second round of patches for v2020.07. Basically we fix RPi4 with 8 GB as up to now U-Boot didn't detect all memory banks. The new RPi4 has 4 memory banks. This leads to the efi stub announcing the wrong amount of memory to the kernel. The second patch fixes boot issues that Corentin had in the kernel CI infrastructure, where he passed a device tree with a memory node with empty values. Hope this will make it into v2020.07. I hold back the USB support as Marek has some comments on the firmware load approach which I wanted to see someone looking into. Regards, Matthias --- The following changes since commit 29b0540d5acc35c8096d7147d7574d0b3ae7dcc0: Merge tag 'bugfixes-for-v2020.07-rc4' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c (2020-05-29 23:54:01 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2020.07.2 for you to fetch changes up to a61cf765f7e3a4ba80453150e16acaaecbd913ac: configs: rpi: set NR_DRAM_BANKS to four (2020-05-30 23:05:47 +0200) rpi4: - set ARCH_FIXUP_FDT_MEMORY - bump NR_DRAM_BANKS to four to enable 8 GB of RAM Corentin Labbe (1): rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY Matthias Brugger (1): configs: rpi: set NR_DRAM_BANKS to four configs/rpi_4_32b_defconfig | 4 ++-- configs/rpi_4_defconfig | 4 ++-- configs/rpi_arm64_defconfig | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
[GIT PULL] rpi: second round for v2020.07
Hi Tom, Please have a look at the second round of patches for RPi. The two patches fixes 8 GB detection on RPi4 and kernel CI booting. Regards, Matthias --- The following changes since commit 29b0540d5acc35c8096d7147d7574d0b3ae7dcc0: Merge tag 'bugfixes-for-v2020.07-rc4' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c (2020-05-29 23:54:01 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2020.07.2 for you to fetch changes up to a61cf765f7e3a4ba80453150e16acaaecbd913ac: configs: rpi: set NR_DRAM_BANKS to four (2020-05-30 23:05:47 +0200) rpi4: - set ARCH_FIXUP_FDT_MEMORY - bump NR_DRAM_BANKS to four to enable 8 GB of RAM Corentin Labbe (1): rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY Matthias Brugger (1): configs: rpi: set NR_DRAM_BANKS to four configs/rpi_4_32b_defconfig | 4 ++-- configs/rpi_4_defconfig | 4 ++-- configs/rpi_arm64_defconfig | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 6/1/20 4:41 PM, Nicolas Saenz Julienne wrote: > On Mon, 2020-06-01 at 13:12 +0200, Marek Vasut wrote: >> On 6/1/20 1:09 PM, Nicolas Saenz Julienne wrote: >>> On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote: On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote: > On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote: >> Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to >> be >> loaded explicitly. Earlier versions didn't need that as they where >> using >> an EEPROM for that purpose. This series takes care of setting up the >> relevant infrastructure and run the firmware loading routine at the >> right moment. >> >> Note that this builds on top of Sylwester Nawrocki's "USB host support >> for Raspberry Pi 4 board" series. >> >> --- > > Please don't forget about this series. The new 8GB RPi4 contains this HW > design > change and USB will not work without it. See this discussion on the > downstream > kernel github, where other OS/bootloaders are hitting the issue: > > https://github.com/raspberrypi/firmware/issues/1402 > > Otherwise, the Linux version of this is already in linux-next: > > >>> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc We're already at 2020.07-rc3 , so unless this is a bugfix (does not look that way), this will have to wait for next release cycle. >>> >>> Of course. As long as it eventually gets in I'm happy (not implying this >>> specific series is flawless, but the overall mechanism). I'm just worried >>> this >>> gets lost. >>> Also, it seems there was a lengthy ongoing discussion, is that already sorted out ? >>> >>> Well, there was some discussion on how to incorporate the platform specific >>> callback into XCHI's code. Which this revision of the series addresses. But, >>> IIRC, that's pretty much it as far as discussion is concerned. >> >> Oh, right, since the firmware loading hook looks like a reset hook, why >> isn't that implemented via reset controller API instead ? > > That could be pretty clean, I hadn't though about it that way. Some questions: > > - Being a PCIe device the XHCI controller doesn't show up in the device-tree. > I > guess it could be added as a child node of pcie-brcmstb, but is that even > acceptable? Yes, there are other such DTs . > - Same goes for xhci-pci being a consumer of the reset controller. Given the > reset scheme is board specific (the chip can be found all over the place, > but > the firmware loading scheme is 100% RPi specific), to what extent we can > introduce that as a binding? I'm not sure what you're asking me here, you'll just have some reset controller in a DT and a phandle from the xhci-controller to this reset controller.
Re: [GIT PULL] rpi: second round for v2020.07
Hi again, On 01/06/2020 17:18, Matthias Brugger wrote: > Hi Tom, > > Please have a look at the second round of patches for RPi. > The two patches fixes 8 GB detection on RPi4 and kernel CI booting. > I forgot to add the links to the CI: https://travis-ci.org/github/mbgg/u-boot/builds/692983026 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/3497 As the last time it run against rpi-next but it's the same commit as the tag. Regards, Matthias > Regards, > Matthias > > --- > > The following changes since commit 29b0540d5acc35c8096d7147d7574d0b3ae7dcc0: > > Merge tag 'bugfixes-for-v2020.07-rc4' of > https://gitlab.denx.de/u-boot/custodians/u-boot-i2c (2020-05-29 23:54:01 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git > tags/rpi-next-2020.07.2 > > for you to fetch changes up to a61cf765f7e3a4ba80453150e16acaaecbd913ac: > > configs: rpi: set NR_DRAM_BANKS to four (2020-05-30 23:05:47 +0200) > > > rpi4: > - set ARCH_FIXUP_FDT_MEMORY > - bump NR_DRAM_BANKS to four to enable 8 GB of RAM > > > Corentin Labbe (1): > rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY > > Matthias Brugger (1): > configs: rpi: set NR_DRAM_BANKS to four > > configs/rpi_4_32b_defconfig | 4 ++-- > configs/rpi_4_defconfig | 4 ++-- > configs/rpi_arm64_defconfig | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) >
Re: Pull request: u-boot-rockchip-20200531
On Mon, Jun 01, 2020 at 07:50:17AM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the rockchip updates/fixes: > - Fix mmc of path after syncfrom kernel dts; > - Add dwc3 host support with DM for rk3399; > - Add usb2phy and typec phy for rockchip platform; > - Migrate board list doc to rockchip.rst; > - Add rk3399 Pinebook Pro board support; > - Update dram_init in board_init and add memory node in SPL; > > > Gitlab ci: > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3509 > > Thanks, > - Kever > > The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-05-27 > 10:56:25 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20200531 > > for you to fetch changes up to a343b4fe739a56ef248f01d96d80d080228b4068: > > spl: add fixed memory node in target fdt also when loading ATF (2020-05-31 > 22:22:07 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] sunxi: Pine64-LTS: SMBIOS properties
On 6/1/20 4:43 PM, André Przywara wrote: > On 01/06/2020 14:56, Heinrich Schuchardt wrote: >> Provide accurate values of the manufacturer and the product name. >> >> PINE Microsystems Inc. is referred to on https://www.pine64.org/contact/. > > While this patch looks alright, I wonder if we can just use the "model" > property in the DT's root node, at least for the product name? This > would not only avoid every defconfig to be touched, but would also cover > all other platforms (at least ARM based ones, probably PPC and MIPS as > well). The relevant code is in lib/smbios.c. For boards that follow the driver model you could read the model node here. But that would unnecessarily increase the code size of the resulting binary. I doubt this would find Tom's sympathy. So you would have to generate the value at compile time. I have no clue how to do that. The model property for the PINE A64 LTS is "Pine64 LTS" while the board is called "PINE A64-LTS" by the manufacturer (https://www.pine64.org/devices/single-board-computers/pine-a64-lts/). So this approach does not lead to the correct result. > > The manufacturer is less straight-forward to handle generically, but the > string before the comma in the DT root's compatible property should give > a hint. The Linux kernel contains a machine readable list of those > prefixes: Documentation/devicetree/bindings/vendor-prefixes.yaml > So we could pick the vendor at compile time based on that. > Of course any config could still overwrite this. SMBIOS_MANUFACTURER defaults to SYS_VENDOR which is defined as "sunxi". The Linux vendor-prefix exists for ARM64 and is missing for the ARM architecture. So this cannot be a general solution. For the Pine64 A64-LTS the vendor-prefix is "allwinner". Neither "sunxi" nor "Allwinner" is the manufacturer of the PINE A64-LTS board. You have to set SMBIOS_MANUFACTURER on the board level. > > Does that make sense? > If people agree, I could try to make a patch for that. Please, reconsider the patch as is. Best regards Heinrich > > Cheers, > Andre. > >> >> Signed-off-by: Heinrich Schuchardt >> --- >> configs/pine64-lts_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig >> index ef108a1a31..a8ff34a376 100644 >> --- a/configs/pine64-lts_defconfig >> +++ b/configs/pine64-lts_defconfig >> @@ -8,8 +8,10 @@ CONFIG_DRAM_ZQ=3881949 >> CONFIG_MMC0_CD_PIN="" >> CONFIG_MMC_SUNXI_SLOT_EXTRA=2 >> CONFIG_SPL_SPI_SUNXI=y >> +CONFIG_SMBIOS_PRODUCT_NAME="PINE A64-LTS" >> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set >> CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-lts" >> CONFIG_SUN8I_EMAC=y >> CONFIG_USB_EHCI_HCD=y >> CONFIG_USB_OHCI_HCD=y >> +CONFIG_SMBIOS_MANUFACTURER="PINE Microsystems Inc." >> -- >> 2.26.2 >> >
Re: [PATCH 1/1] fastboot: add support for 'reboot fastboot' command
On Mon, Jun 1, 2020 at 1:55 PM Roman Kovalivskyi
wrote:
>
> On 27.05.20 15:56, Alex Kiernan wrote:
>
> > On Wed, May 27, 2020 at 12:14 PM Roman Kovalivskyi
> > wrote:
> >> From: Roman Stratiienko
> >>
> >> Android 10 adds support for dynamic partitions and in order to support
> >> them userspace fastboot must be used[1]. New tool fastbootd is
> >> included into recovery image.
> >>
> >> Userspace fastboot works from recovery and is launched if:
> >> 1) - Dynamic partitioning is enabled
> >> 2) - Boot control block has 'boot-fastboot' value into command field
> >> The bootloader is expected to load and boot into the recovery image
> >> upon seeing boot-fastboot in the BCB command. Recovery then parses the
> >> BCB message and switches to fastbootd mode[2].
> >>
> >> Please note that boot script is expected to handle 'boot-fastboot'
> >> command in BCB and load into recovery mode.
> >>
> >> Bootloader must support 'reboot fastboot' command which should reboot
> >> device into userspace fastboot to accomodate those changes[3].
> >>
> >> [1] - https://source.android.com/devices/bootloader/fastbootd
> >> [2] -
> >> https://source.android.com/devices/bootloader/fastbootd#unified_fastboot_and_recovery
> >> [3] -
> >> https://source.android.com/devices/bootloader/fastbootd#modifications_to_the_bootloader
> >>
> >> Signed-off-by: Roman Kovalivskyi
> >> Signed-off-by: Roman Stratiienko
> >> Change-Id: I9d2bdc9a6f6f31ea98572fe155e1cc8341e9af76
> >> ---
> >> drivers/fastboot/fb_command.c | 42 +
> >> drivers/fastboot/fb_common.c| 31
> >> drivers/usb/gadget/f_fastboot.c | 2 ++
> >> include/fastboot.h | 9 +++
> >> 4 files changed, 84 insertions(+)
> >>
> >> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> >> index 49f6a61c3745..3616133b880e 100644
> >> --- a/drivers/fastboot/fb_command.c
> >> +++ b/drivers/fastboot/fb_command.c
> >> @@ -37,6 +37,8 @@ static void flash(char *, char *);
> >> static void erase(char *, char *);
> >> #endif
> >> static void reboot_bootloader(char *, char *);
> >> +static void reboot_fastbootd(char *, char *);
> >> +static void reboot_recovery(char *, char *);
> >> #if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
> >> static void oem_format(char *, char *);
> >> #endif
> >> @@ -79,6 +81,14 @@ static const struct {
> >> .command = "reboot-bootloader",
> >> .dispatch = reboot_bootloader
> >> },
> >> + [FASTBOOT_COMMAND_REBOOT_FASTBOOTD] = {
> >> + .command = "reboot-fastboot",
> >> + .dispatch = reboot_fastbootd
> >> + },
> >> + [FASTBOOT_COMMAND_REBOOT_RECOVERY] = {
> >> + .command = "reboot-recovery",
> >> + .dispatch = reboot_recovery
> >> + },
> >> [FASTBOOT_COMMAND_SET_ACTIVE] = {
> >> .command = "set_active",
> >> .dispatch = okay
> >> @@ -307,12 +317,44 @@ static void erase(char *cmd_parameter, char
> >> *response)
> >> */
> >> static void reboot_bootloader(char *cmd_parameter, char *response)
> >> {
> >> +#if CONFIG_IS_ENABLED(CMD_BCB)
> >> + if (fastboot_set_flag("bootonce-bootloader"))
> >> +#else
> >> if (fastboot_set_reboot_flag())
> >> +#endif
> >> fastboot_fail("Cannot set reboot flag", response);
> >> else
> >> fastboot_okay(NULL, response);
> >> }
> >>
> >> +/**
> >> + * reboot_fastbootd() - Sets reboot fastboot flag.
> >> + *
> >> + * @cmd_parameter: Pointer to command parameter
> >> + * @response: Pointer to fastboot response buffer
> >> + */
> >> +static void reboot_fastbootd(char *cmd_parameter, char *response)
> >> +{
> >> + if (fastboot_set_flag("boot-fastboot"))
> >> + fastboot_fail("Cannot set fastboot flag", response);
> >> + else
> >> + fastboot_okay(NULL, response);
> >> +}
> >> +
> >> +/**
> >> + * reboot_recovery() - Sets reboot recovery flag.
> >> + *
> >> + * @cmd_parameter: Pointer to command parameter
> >> + * @response: Pointer to fastboot response buffer
> >> + */
> >> +static void reboot_recovery(char *cmd_parameter, char *response)
> >> +{
> >> + if (fastboot_set_flag("boot-recovery"))
> >> + fastboot_fail("Cannot set recovery flag", response);
> >> + else
> >> + fastboot_okay(NULL, response);
> >> +}
> >> +
> >> #if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
> >> /**
> >> * oem_format() - Execute the OEM format command
> >> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> >> index c3735a44af74..b6401640ad06 100644
> >> --- a/drivers/fastboot/fb_common.c
> >> +++ b/drivers/fastboot/fb_common.c
> >> @@ -93,6 +93,37 @@ int __weak fastboot_set_reboot_flag(void)
> >> return -ENOSYS;
> >> }
> >>
> >> +/**
> >> + * fastboot_set_flag() - Set flag to indicate reboot-recovery
> >> + *
> >> + * Set flag which
Re: [PATCH 2/2] sun8i-emac: Added sun8i-v3s-emac example to sun8i-v3s.dtsi
On Wed, May 27, 2020 at 7:03 PM Benedikt-Alexander Mokroß wrote: > > This optional patch adds the needed device-tree node to sun8i-v3s.dtsi to > enable > ethernet for sun8i-v3s boards. Better to sync the dts(i) from Linux (-next) with proper tag details.
Re: [PATCH v8 1/2] spi: ca_sflash: Add CAxxxx SPI Flash Controller
On Fri, May 22, 2020 at 6:18 AM Alex Nemirovsky
wrote:
>
> From: Pengpeng Chen
>
> Add SPI Flash controller driver for Cortina Access
> CA SoCs
>
> Signed-off-by: Pengpeng Chen
> Signed-off-by: Alex Nemirovsky
> CC: Jagan Teki
> CC: Vignesh R
> CC: Tom Rini
>
> ---
>
> Changes in v8:
> - No code change
> - Split out individual driver from Cortina Package 2 patch series
> to help streamline acceptence into master
>
> Changes in v7:
> - Replace substring "OPCODE" with "OP" in MACROs to help
> reduce code line lengths
> - Replace substring "_MASK" with "_MSK" in MACROs to help
> reduce code line lengths
>
> Changes in v5: None
> Changes in v3:
> - Fixup syntax issues related to checkpatch.pl cleanup
>
> MAINTAINERS | 8 +
> drivers/spi/Kconfig | 8 +
> drivers/spi/Makefile| 1 +
> drivers/spi/ca_sflash.c | 576
>
> 4 files changed, 593 insertions(+)
> create mode 100644 drivers/spi/ca_sflash.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8add9d4..57ce45e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -181,6 +181,10 @@ F: drivers/gpio/cortina_gpio.c
> F: drivers/watchdog/cortina_wdt.c
> F: drivers/serial/serial_cortina.c
> F: drivers/mmc/ca_dw_mmc.c
> +F: drivers/i2c/i2c-cortina.c
> +F: drivers/i2c/i2c-cortina.h
> +F: drivers/led/led_cortina.c
> +F: drivers/spi/ca_sflash.c
>
> ARM/CZ.NIC TURRIS MOX SUPPORT
> M: Marek Behun
> @@ -732,6 +736,10 @@ F: drivers/gpio/cortina_gpio.c
> F: drivers/watchdog/cortina_wdt.c
> F: drivers/serial/serial_cortina.c
> F: drivers/mmc/ca_dw_mmc.c
> +F: drivers/i2c/i2c-cortina.c
> +F: drivers/i2c/i2c-cortina.h
> +F: drivers/led/led_cortina.c
These changes are unrelated to SPI, keep out of this patch.
> +F: drivers/spi/ca_sflash.c
>
> MIPS MSCC
> M: Gregory CLEMENT
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index dccd5ea..09f2a2a 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -106,6 +106,14 @@ config BCMSTB_SPI
> be used to access the SPI flash on platforms embedding this
> Broadcom SPI core.
>
> +config CORTINA_SFLASH
> + bool "Cortina-Access Serial Flash controller driver"
> + depends on DM_SPI && SPI_MEM
> + help
> + Enable the Cortina-Access Serial Flash controller driver. This
> driver
> + can be used to access the SPI NOR/NAND flash on platforms embedding
> this
> + Cortina-Access IP core.
> +
> config CADENCE_QSPI
> bool "Cadence QSPI driver"
> help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 6441694..5e53f11 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_BCM63XX_SPI) += bcm63xx_spi.o
> obj-$(CONFIG_BCMSTB_SPI) += bcmstb_spi.o
> obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
> obj-$(CONFIG_CF_SPI) += cf_spi.o
> +obj-$(CONFIG_CORTINA_SFLASH) += ca_sflash.o
> obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
> obj-$(CONFIG_DESIGNWARE_SPI) += designware_spi.o
> obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
> diff --git a/drivers/spi/ca_sflash.c b/drivers/spi/ca_sflash.c
> new file mode 100644
> index 000..00af6bf
> --- /dev/null
> +++ b/drivers/spi/ca_sflash.c
> @@ -0,0 +1,576 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Driver for Cortina SPI-FLASH Controller
> + *
> + * Copyright (C) 2020 Cortina Access Inc. All Rights Reserved.
> + *
> + * Author: PengPeng Chen
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct ca_sflash_regs {
> + u32 idr;/* 0x00:Flash word ID Register */
> + u32 tc; /* 0x04:Flash Timeout Counter Register */
> + u32 sr; /* 0x08:Flash Status Register */
> + u32 tr; /* 0x0C:Flash Type Register */
> + u32 asr;/* 0x10:Flash ACCESS START/BUSY Register */
> + u32 isr;/* 0x14:Flash Interrupt Status Register */
> + u32 imr;/* 0x18:Flash Interrupt Mask Register */
> + u32 fcr;/* 0x1C:NAND Flash FIFO Control Register */
> + u32 ffsr; /* 0x20:Flash FIFO Status Register */
> + u32 ffar; /* 0x24:Flash FIFO ADDRESS Register */
> + u32 ffmar; /* 0x28:Flash FIFO MATCHING ADDRESS Register
> */
> + u32 ffdr; /* 0x2C:Flash FIFO Data Register */
> + u32 ar; /* 0x30:Serial Flash Access Register */
> + u32 ear;/* 0x34:Serial Flash Extend Access Register */
> + u32 adr;/* 0x38:Serial Flash ADdress Register */
> + u32 dr; /* 0x3C:Serial Flash Data Register */
> + u3
Re: [PATCH u-boot] eth/r8152: update the firmware
On 6/1/20 10:42 AM, Hayes Wang wrote: > Update the firmware to improve compatibility for none-intel USB > host controller. Can you be more specific about the problem you are fixing here ? What is the problem ?
Re: [PATCH v8 2/2] board: presidio-asic: Add SPI NOR support
On Fri, May 22, 2020 at 6:18 AM Alex Nemirovsky
wrote:
>
> Add SPI NOR support for Cortina Access
> Presidio Engineering Board
>
> Signed-off-by: Alex Nemirovsky
> CC: Jagan Teki
> CC: Vignesh R
> CC: Tom Rini
>
> ---
>
> Changes in v8: None
> Changes in v7: None
> Changes in v5:
> - NAND support removed from presidio-asic board DT.
>
> Changes in v3: None
>
> arch/arm/dts/ca-presidio-engboard.dts| 6 +--
> board/cortina/presidio-asic/presidio.c | 16 ++-
> configs/cortina_presidio-asic-spi-nand_defconfig | 48 +++
> configs/cortina_presidio-asic-spi-nor_defconfig | 59
>
> 4 files changed, 124 insertions(+), 5 deletions(-)
> create mode 100644 configs/cortina_presidio-asic-spi-nand_defconfig
> create mode 100644 configs/cortina_presidio-asic-spi-nor_defconfig
>
> diff --git a/arch/arm/dts/ca-presidio-engboard.dts
> b/arch/arm/dts/ca-presidio-engboard.dts
> index c03dacc..34148b9 100644
> --- a/arch/arm/dts/ca-presidio-engboard.dts
> +++ b/arch/arm/dts/ca-presidio-engboard.dts
> @@ -55,15 +55,13 @@
> };
>
> sflash: sflash-controller@f4324000 {
> - #address-cells = <2>;
> - #size-cells = <1>;
> compatible = "cortina,ca-sflash";
> reg = <0x0 0xf4324000 0x50>;
> reg-names = "sflash-regs";
> flash@0 {
> compatible = "jedec,spi-nor";
> - spi-rx-bus-width = <1>;
> - spi-max-frequency = <10800>;
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <4>;
Unrelated change, please prepare separate patch.
> };
> };
> };
> diff --git a/board/cortina/presidio-asic/presidio.c
> b/board/cortina/presidio-asic/presidio.c
> index 3c132f1..883bd2e 100644
> --- a/board/cortina/presidio-asic/presidio.c
> +++ b/board/cortina/presidio-asic/presidio.c
> @@ -16,7 +16,7 @@
> #include
> #include
> #include
> -
> +#include
> DECLARE_GLOBAL_DATA_PTR;
>
> #define CA_PERIPH_BASE 0xE000UL
> @@ -72,9 +72,23 @@ static noinline int invoke_psci_fn_smc(u64 function_id,
> u64 arg0, u64 arg1,
> return function_id;
> }
>
> +#ifdef CONFIG_CORTINA_SFLASH
> +static int init_sflash(void)
> +{
> + struct udevice *dev;
> +
> + uclass_first_device(UCLASS_SPI, &dev);
I was wondering why SPI here is probing separately, we have sf to
probe at run time?
Re: [PATCH] phy: sun4i-usb: Align H6 initialization logic with the kernel
On Wed, May 13, 2020 at 2:22 AM Roman Stratiienko
wrote:
>
> H6 SOC needs additional initialization of PHY registers. Corresponding
> changes can be found in the kernel patch [1].
>
> Without this changes there is no enumeration of 'musb' gadget.
>
> [1] -
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae409cc7c3cdb9ac4a1dba3eae70efec3d6b6c79
>
> Fixes: 35fa673e0e5f ("sunxi: phy: Add USB PHY support for Allwinner H6")
> Signed-off-by: Roman Stratiienko
> ---
Applied to u-boot-sunxi/master
Re: [PATCH] sunxi: Silence warning about non-static inline function
On Fri, May 8, 2020 at 4:31 AM Samuel Holland wrote:
>
> When compiling with CONFIG_SPL_SERIAL=n, gcc warns about
> mbus_configure_port not being marked as static:
>
> In file included from include/common.h:34,
> from arch/arm/mach-sunxi/dram_sunxi_dw.c:11:
> include/log.h:185:4: warning: 'printf' is static but used in inline function
> 'mbus_configure_port' which is not static
> 185 |printf(pr_fmt(fmt), ##args); \
> |^~
> include/log.h:192:2: note: in expansion of macro 'debug_cond'
> 192 | debug_cond(_DEBUG, fmt, ##args)
> | ^~
> arch/arm/mach-sunxi/dram_sunxi_dw.c:100:2: note: in expansion of macro 'debug'
> 100 | debug("MBUS port %d cfg0 %08x cfg1 %08x\n", port, cfg0, cfg1);
> | ^
>
> Fix this by updating the function accordingly.
>
> Signed-off-by: Samuel Holland
> ---
Applied to u-boot-sunxi/master
Re: [PATCH] Correct sun8i-v3s SRAM size
On Tue, Apr 28, 2020 at 9:26 PM Benedikt-Alexander Mokroß wrote: > > According to the Datasheet, the V3s has a 32KiB SRAM. > This patch corrects CONFIG_SPL_MAX_SIZE and LOW_LEVEL_SRAM_STACK > accordingly. Look like the existing value has taken from allwinner BSP, but did you find any issues with the existing one? Jagan.
Re: [PATCH 1/3] net: sun8i_emac: Use consistent clock bitfield definitions
On Fri, May 8, 2020 at 4:40 AM Samuel Holland wrote: > > While the R40 uses a different register for EMAC clock configuration > than other chips, the register has a very similar layout. Reuse the > existing bitfield definitions in this file, since they match. > > This allows the driver to compile on the H6 platform, where the > CCM_GMAC_CTRL definitions are not present. > > Signed-off-by: Samuel Holland > --- Applied to u-boot-sunxi/master
Re: [PATCH 1/3] spl: fit: Minimally parse OS properties with FIT_IMAGE_TINY
On Fri, May 8, 2020 at 4:49 AM Samuel Holland wrote: > > Some boards, specifically 64-bit Allwinner boards (sun50i), are > extremely limited on SPL size. One strategy that was used to make space > was to remove the FIT "os" property parsing code, because it uses a > rather large lookup table. > > However, this forces the legacy FIT parsing code path, which requires > the "firmware" entry in the FIT to reference the U-Boot binary, even if > U-Boot is not the next binary in the boot sequence (for example, on > sun50i boards, ATF is run first). > > This prevents the same FIT image from being used with a SPL with > CONFIG_SPL_FIT_IMAGE_TINY=n and CONFIG_SPL_ATF=y, because the boot > method selection code looks at `spl_image.os`, which is only set from > the "firmware" entry's "os" property. > > To be able to use CONFIG_SPL_ATF=y, the "firmware" entry in the FIT > must be ATF, and U-Boot must be a loadable. For this to work, we need to > parse the "os" property just enough to tell U-Boot from other images, so > we can find it in the loadables list to append the FDT, and so we don't > try to append the FDT to ATF (which could clobber adjacent firmware). > > So add the minimal code necessary to distinguish U-Boot/non-U-Boot > loadables with CONFIG_SPL_FIT_IMAGE_TINY=y. This adds about 300 bytes, > much less than the 7400 bytes added by CONFIG_SPL_FIT_IMAGE_TINY=n. > > Signed-off-by: Samuel Holland > --- + Andre
[PATCH] doc: driver-model: Update SPI migration status
DM_SPI migration status fror v2020.07 removed: lpc32xx_ssp.c sh_spi.c Signed-off-by: Jagan Teki --- doc/driver-model/migration.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/doc/driver-model/migration.rst b/doc/driver-model/migration.rst index d1fc0e6a78..de8c1f9e72 100644 --- a/doc/driver-model/migration.rst +++ b/doc/driver-model/migration.rst @@ -69,8 +69,6 @@ to move the migration with in the deadline. No dm conversion yet:: drivers/spi/fsl_espi.c - drivers/spi/lpc32xx_ssp.c - drivers/spi/sh_spi.c drivers/spi/soft_spi_legacy.c * Status: In progress -- 2.25.1
Re: [RFC PATCH 1/1] gpio: Handle NULL pointers gracefully
Hi Pratyush,
On Fri, 29 May 2020 at 16:04, Pratyush Yadav wrote:
>
> Prepare the way for a managed GPIO API by handling NULL pointers without
> crashing or failing. validate_desc() comes from Linux with the prints
> removed to reduce code size.
Please can you add a little detail as to why this is needed? Are you
trying to pass a NULL GPIO descriptor to the function?
>
> Signed-off-by: Jean-Jacques Hiblot
> Signed-off-by: Pratyush Yadav
> ---
> drivers/gpio/Kconfig | 9
> drivers/gpio/gpio-uclass.c | 86 ++
> include/asm-generic/gpio.h | 2 +-
> 3 files changed, 88 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index d87f6cc105..f8b6bcdf44 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -36,6 +36,15 @@ config TPL_DM_GPIO
> particular GPIOs that they provide. The uclass interface
> is defined in include/asm-generic/gpio.h.
>
> +config GPIO_VALIDATE_DESC
> + bool "Check if GPIO descriptor is NULL and bail out if it is"
> + depends on DM_GPIO
> + default y
> + help
> + If a GPIO is optional, the GPIO descriptor is NULL. In that
> + case, calls should bail out instead of causing NULL pointer
> + access.
Can you update the gpio function docs in the header file with this info?
> +
> config GPIO_HOG
> bool "Enable GPIO hog support"
> depends on DM_GPIO
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index 9eeab22eef..6b97d3aaff 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -20,6 +20,25 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#ifdef CONFIG_GPIO_VALIDATE_DESC
> +/*
> + * This descriptor validation needs to be inserted verbatim into each
> + * function taking a descriptor, so we need to use a preprocessor
> + * macro to avoid endless duplication. If the desc is NULL it is an
> + * optional GPIO and calls should just bail out.
Is the macro defined elsewhere?
> + */
> +static inline int validate_desc(const struct gpio_desc *desc)
> +{
> + if (!desc)
> + return 0;
> + if (IS_ERR(desc))
> + return PTR_ERR(desc);
> + if (!desc->dev)
> + return -EINVAL;
> + return 1;
> +}
#else
static inline int validate_desc(const struct gpio_desc *desc)
{
return 1;
}
> +#endif
> +
> /**
> * gpio_desc_init() - Initialize the GPIO descriptor
> *
> @@ -303,11 +322,19 @@ int gpio_hog_lookup_name(const char *name, struct
> gpio_desc **desc)
>
> int dm_gpio_request(struct gpio_desc *desc, const char *label)
> {
> - struct udevice *dev = desc->dev;
> + struct udevice *dev;
> struct gpio_dev_priv *uc_priv;
> char *str;
> int ret;
>
> +#ifdef CONFIG_GPIO_VALIDATE_DESC
Please drop the #ifdefs and use the static inline thing from above.
> + ret = validate_desc(desc);
> + if (ret <= 0)
> + return ret;
Here you are returning 0 when you did not successfully request the
GPIO.You should return -ENOENT, otherwise callers have no idea what
happened and will get confused.
> +#endif
> +
> + dev = desc->dev;
> +
> uc_priv = dev_get_uclass_priv(dev);
> if (uc_priv->name[desc->offset])
> return -EBUSY;
> @@ -434,6 +461,14 @@ static int check_reserved(const struct gpio_desc *desc,
> const char *func)
> {
> struct gpio_dev_priv *uc_priv;
>
> +#ifdef CONFIG_GPIO_VALIDATE_DESC
> + int ret;
> +
> + ret = validate_desc(desc);
> + if (ret <= 0)
> + return ret;
> +#endif
> +
> if (!dm_gpio_is_valid(desc))
> return -ENOENT;
>
> @@ -510,6 +545,12 @@ int dm_gpio_get_value(const struct gpio_desc *desc)
> {
> int ret;
>
> +#ifdef CONFIG_GPIO_VALIDATE_DESC
> + ret = validate_desc(desc);
> + if (ret <= 0)
> + return ret;
> +#endif
> +
> ret = check_reserved(desc, "get_value");
> if (ret)
> return ret;
> @@ -521,6 +562,12 @@ int dm_gpio_set_value(const struct gpio_desc *desc, int
> value)
> {
> int ret;
>
> +#ifdef CONFIG_GPIO_VALIDATE_DESC
> + ret = validate_desc(desc);
> + if (ret <= 0)
> + return ret;
> +#endif
> +
> ret = check_reserved(desc, "set_value");
> if (ret)
> return ret;
> @@ -572,11 +619,21 @@ static int check_dir_flags(ulong flags)
>
> static int _dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong flags)
> {
> - struct udevice *dev = desc->dev;
> - struct dm_gpio_ops *ops = gpio_get_ops(dev);
> - struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> + struct udevice *dev;
> + struct dm_gpio_ops *ops;
> + struct gpio_dev_priv *uc_priv;
> int ret = 0;
>
> +#ifdef CONFIG_GPIO_VALIDATE_DESC
> + ret = validate_desc(desc);
> + if (ret <= 0)
> +
[PATCH v2] env: sf: Free the old env_flash
env_flash is a global flash pointer, and the probe would
happen only if env_flash is NULL, but there is no checking
and free the pointer if is not NULL.
So, this patch frees the old env_flash, and get the probed
flash in to env_flash pointer and finally check if is not NULL.
Suggested-by: Pratyush Yadav
Signed-off-by: Jagan Teki
---
Changes for v2:
- change suggested by Pratyush.
env/sf.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/env/sf.c b/env/sf.c
index 23de5a3495..02ed846fc7 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -53,15 +53,14 @@ static int setup_flash_device(void)
env_flash = dev_get_uclass_priv(new);
#else
+ if (env_flash)
+ spi_flash_free(env_flash);
+ env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
+ CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
if (!env_flash) {
- env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
- CONFIG_ENV_SPI_CS,
- CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
- if (!env_flash) {
- env_set_default("spi_flash_probe() failed", 0);
- return -EIO;
- }
+ env_set_default("spi_flash_probe() failed", 0);
+ return -EIO;
}
#endif
return 0;
--
2.25.1
Re: [PATCH] rockchip: rockpro64: Set cooling levels for pwm-fan
On Fri, 2020-05-29 at 13:00 -0600, Simon Glass wrote: > Hi Kurt, > > On Fri, 29 May 2020 at 06:42, Kurt Miller wrote: > > > > > > On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote: > > > > > > On Thu, May 28, 2020 at 8:32 PM Kurt Miller > > > wrote: > > > > > > > > > > > > > > > > The cooling levels are tuned to the fan that comes with the rockpro64 > > > > NAS > > > > case. A gpu_thermal zone was not added because having two active cooling > > > > maps control one physical fan causes them to compete for the fan speed > > > > which results in erratic fan behavior. > > > Is there any reason this shouldn't go to the linux kernel first and > > > then be synced back to the standard rk3399-rockpro64.dtsi? > > Is that a requirement? I do my primary development on OpenBSD and > > while I use Linux for work tasks, I don't have available time right > > now to push these changes to Linux kernel first. > > > The problem is that we need to keep Linux and U-Boot in sync. If a DT > change is submitted only to one then it isn't clear who is taking on > the task of syncing them up. > > You don't actually need to be using Linux to send a DT change - just > clone Linux, apply your patch and send to devicet...@vger.kernel.org. > I wonder if it would be good enough to cc that group and the Linux > maintainer on these patches, assuming the files are currently in sync? > But probably a new patch is needed. > Thank you for the pointers. I'll give that a try. Best, -Kurt
Re: [PATCH v4 0/5] TI Ethernet PHY changes
Did I miss the maintainer for this series? Dan On 5/11/20 7:52 PM, Dan Murphy wrote: Bump to the series On 5/4/20 4:14 PM, Dan Murphy wrote: Hello The addition of the DP83867 driver to uboot was done in a generic way that made it a bit difficult to bring in new PHY drivers. The difficulty came in the config flags and the phy_init function. The change is to make the flags and init for the DP83867 more specific to the DP83867 device to make way to add more TI PHYs to uBoot. In addition the DP8382X PHY is a generic PHY driver that does not need any special handling to establish a link. Customers have requested that at the very least there be a way to know if the PHY attached is the PHY that is connected as "Generic PHY" is not really descriptive. These patches adds the registrations for TI Generic PHYs to associcate a TI PHY ID with a PHY name. Porting PHY helper routines to set and clear bits to facilitate easier side porting of ethernet kernel drivers to uBoot. Also fixed and added missing or kernel doc documentation in the phy.h file. Dan Dan Murphy (5): net: phy: Add missing kernel doc to phy functions net: phy: Fix kernel doc issues in phy.h net: phy: Add helper routines to set and clear bits net: phy: Add support for TI PHY init net: phy: Add DP8382x phy registration to TI PHY init configs/am65x_evm_a53_defconfig | 2 +- configs/am65x_hs_evm_a53_defconfig | 2 +- configs/dra7xx_evm_defconfig | 2 +- configs/dra7xx_hs_evm_defconfig | 2 +- configs/dra7xx_hs_evm_usb_defconfig | 2 +- configs/j721e_evm_a72_defconfig | 2 +- configs/j721e_hs_evm_a72_defconfig | 2 +- configs/k2g_evm_defconfig | 2 +- configs/xilinx_versal_virt_defconfig | 2 +- configs/xilinx_zynqmp_virt_defconfig | 2 +- drivers/net/phy/Kconfig | 15 drivers/net/phy/Makefile | 3 +- drivers/net/phy/dp83867.c | 3 +- drivers/net/phy/ti_phy_init.c | 101 drivers/net/phy/ti_phy_init.h | 15 include/phy.h | 112 --- 16 files changed, 246 insertions(+), 23 deletions(-) create mode 100644 drivers/net/phy/ti_phy_init.c create mode 100644 drivers/net/phy/ti_phy_init.h
[PATCH v2 02/13] armv8: layerscape: pretty print info about SMP cores
Make the print of the starting address a debug output and pretty print
the info about online cores.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/mp.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index e078d1cd37..b5916ff3f3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -98,7 +99,7 @@ int fsl_layerscape_wake_seconday_cores(void)
(unsigned long)table +
(CONFIG_MAX_CPUS*SPIN_TABLE_ELEM_SIZE));
- printf("Waking secondary cores to start from %lx\n", gd->relocaddr);
+ debug("Waking secondary cores to start from %lx\n", gd->relocaddr);
#ifdef CONFIG_FSL_LSCH3
gur_out32(&gur->bootlocptrh, (u32)(gd->relocaddr >> 32));
@@ -168,11 +169,11 @@ int fsl_layerscape_wake_seconday_cores(void)
udelay(10);
}
if (timeout <= 0) {
- printf("Not all cores (0x%x) are up (0x%x)\n",
- cores, cpu_up_mask);
+ printf("CPU: Failed to bring up some cores (mask 0x%x)\n",
+ cores ^ cpu_up_mask);
return 1;
}
- printf("All (%d) cores are up.\n", hweight32(cores));
+ printf("CPU: %d cores online\n", hweight32(cores));
return 0;
}
--
2.20.1
[PATCH v2 04/13] armv8: layerscape: move spin table into own module
Move it out of lowlevel.S into spintable.S. On layerscape, the secondary CPUs are brought up in main u-boot. This will make it possible to only compile the spin table code for the main u-boot and omit it in SPL. This saves about 720 bytes in the SPL. Signed-off-by: Michael Walle --- arch/arm/cpu/armv8/fsl-layerscape/Makefile| 2 +- arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 154 + arch/arm/cpu/armv8/fsl-layerscape/spintable.S | 155 ++ 3 files changed, 161 insertions(+), 150 deletions(-) create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/spintable.S diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile index e398aecd12..9ecb372b4e 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile @@ -6,7 +6,7 @@ obj-y += cpu.o obj-y += lowlevel.o obj-y += soc.o ifndef CONFIG_SPL_BUILD -obj-$(CONFIG_MP) += mp.o +obj-$(CONFIG_MP) += mp.o spintable.o obj-$(CONFIG_OF_LIBFDT) += fdt.o endif obj-$(CONFIG_SPL) += spl.o diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index d75013eb9c..a519f6ed67 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -11,14 +11,16 @@ #include #include #include -#ifdef CONFIG_MP -#include -#endif #ifdef CONFIG_FSL_LSCH3 #include #endif #include + .align 3 + .weak secondary_boot_addr +secondary_boot_addr: + .quad 0 + /* Get GIC offset * For LS1043a rev1.0, GIC base address align with 4k. * For LS1043a rev1.1, if DCFG_GIC400_ALIGN[GIC_ADDR_BIT] @@ -424,149 +426,3 @@ ENTRY(__asm_flush_l3_dcache) ret ENDPROC(__asm_flush_l3_dcache) #endif /* CONFIG_SYS_FSL_HAS_CCN504 */ - -#ifdef CONFIG_MP - .align 3 - .global secondary_boot_addr -secondary_boot_addr: - .quad secondary_boot_func - - /* Keep literals not used by the secondary boot code outside it */ - .ltorg - - /* Using 64 bit alignment since the spin table is accessed as data */ - .align 4 - .global secondary_boot_code - /* Secondary Boot Code starts here */ -secondary_boot_code: - .global __spin_table -__spin_table: - .space CONFIG_MAX_CPUS*SPIN_TABLE_ELEM_SIZE - - .align 2 -ENTRY(secondary_boot_func) - /* -* MPIDR_EL1 Fields: -* MPIDR[1:0] = AFF0_CPUID <- Core ID (0,1) -* MPIDR[7:2] = AFF0_RES -* MPIDR[15:8] = AFF1_CLUSTERID <- Cluster ID (0,1,2,3) -* MPIDR[23:16] = AFF2_CLUSTERID -* MPIDR[24] = MT -* MPIDR[29:25] = RES0 -* MPIDR[30] = U -* MPIDR[31] = ME -* MPIDR[39:32] = AFF3 -* -* Linear Processor ID (LPID) calculation from MPIDR_EL1: -* (We only use AFF0_CPUID and AFF1_CLUSTERID for now -* until AFF2_CLUSTERID and AFF3 have non-zero values) -* -* LPID = MPIDR[15:8] | MPIDR[1:0] -*/ - mrs x0, mpidr_el1 - ubfmx1, x0, #8, #15 - ubfmx2, x0, #0, #1 - orr x10, x2, x1, lsl #2 /* x10 has LPID */ - ubfmx9, x0, #0, #15 /* x9 contains MPIDR[15:0] */ - /* -* offset of the spin table element for this core from start of spin -* table (each elem is padded to 64 bytes) -*/ - lsl x1, x10, #6 - ldr x0, =__spin_table - /* physical address of this cpus spin table element */ - add x11, x1, x0 - - ldr x0, =__real_cntfrq - ldr x0, [x0] - msr cntfrq_el0, x0 /* set with real frequency */ - str x9, [x11, #16] /* LPID */ - mov x4, #1 - str x4, [x11, #8] /* STATUS */ - dsb sy - -slave_cpu: - wfe - ldr x0, [x11] - cbz x0, slave_cpu -#ifndef CONFIG_ARMV8_SWITCH_TO_EL1 - mrs x1, sctlr_el2 -#else - mrs x1, sctlr_el1 -#endif - tbz x1, #25, cpu_is_le - rev x0, x0 /* BE to LE conversion */ -cpu_is_le: - ldr x5, [x11, #24] - cbz x5, 1f - -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - adr x4, secondary_switch_to_el1 - ldr x5, =ES_TO_AARCH64 -#else - ldr x4, [x11] - ldr x5, =ES_TO_AARCH32 -#endif - bl secondary_switch_to_el2 - -1: -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - adr x4, secondary_switch_to_el1 -#else - ldr x4, [x11] -#endif - ldr x5, =ES_TO_AARCH64 - bl secondary_switch_to_el2 - -ENDPROC(secondary_boot_func) - -ENTRY(secondary_switch_to_el2) - switch_el x6, 1f, 0f, 0f -0: ret -1: armv8_switch_to_el2_m x4, x5, x6 -ENDPROC(secondary_switch_to_el2) - -ENTRY(secondary_switch_to_el1) - mrs x0, mpidr_el1 - ubfmx1, x0, #8, #15 - ubfmx2, x0, #0, #1 - orr x10, x2, x1, lsl #2 /* x10 has LPID */ - - lsl x1, x10, #6 -
[PATCH v2 06/13] armv8: layerscape: fix alignment for spin table
Fix the alignment so it will match the comments. The spin table has to be 8 byte aligned, so ".align 3" is enough. Signed-off-by: Michael Walle --- arch/arm/cpu/armv8/fsl-layerscape/spintable.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S index ac9c622aee..a92f930e04 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S @@ -19,7 +19,7 @@ secondary_boot_addr: .ltorg /* Using 64 bit alignment since the spin table is accessed as data */ - .align 4 + .align 3 .global secondary_boot_code /* Secondary Boot Code starts here */ secondary_boot_code: @@ -144,7 +144,7 @@ ENDPROC(secondary_switch_to_el1) .ltorg /* 64 bit alignment for elements accessed as data */ - .align 4 + .align 3 .global __real_cntfrq __real_cntfrq: .quad COUNTER_FREQUENCY -- 2.20.1
[PATCH v2 00/13] armv8: layerscape: spin table relocation fixes and cleanups
Fix bootefi on layerscape boards which use spin table for secondary cores bringup. There two main issues here: (1) bootefi doesn't kick the secondary cores (2) bootefi reserves a 64kb region for runtime services code on ARM64 which overlaps the spin table code. We will fix (1) by removing the need to kick the secondary cores. For (2), we will make the spin table code relocatable and if the efi_loader support is enabled we will dynamically allocate a page for the spin table code and relocate it there. While we are at it, clean up the whole spin table code for layerscape. Please note, no current board in u-boot should be using spin tables, because NXP officially only supports TF-A, which uses PSCI for secondary cores booting. Only the pending Kontron SMARC-sAL28 board will be using this method. U-Boot support is still pending, see: https://patchwork.ozlabs.org/project/uboot/list/?series=175926 This was tested on said board, both with CONFIG_ARMV8_SWITCH_TO_EL1 defined and undefined. Michael Walle (13): armv8: layerscape: fix spin-table support armv8: layerscape: pretty print info about SMP cores armv8: layerscape: properly use CPU_RELEASE_ADDR armv8: layerscape: move spin table into own module armv8: layerscape: load function pointer using ADR armv8: layerscape: fix alignment for spin table armv8: layerscape: remove determine_mp_bootpg() armv8: layerscape: simplify get_spin_tbl_addr() calls armv8: layerscape: make wake_secondary_core_n() static armv8: freescale: drop first .ltorg directive in spintable.S armv8: layerscape: clean exported symbols in spintable.S armv8: layerscape: relocate spin table if EFI_LOADER is enabled armv8: layerscape: rework spin table arch/arm/cpu/armv8/fsl-layerscape/Makefile| 2 +- arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 +- arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 165 ++ arch/arm/cpu/armv8/fsl-layerscape/mp.c| 79 ++--- arch/arm/cpu/armv8/fsl-layerscape/spintable.S | 118 + arch/arm/include/asm/arch-fsl-layerscape/mp.h | 8 +- include/configs/kontron_sl28.h| 2 +- include/configs/ls1028a_common.h | 2 +- include/configs/ls1043a_common.h | 2 +- include/configs/ls1046a_common.h | 2 +- include/configs/ls1088a_common.h | 2 +- include/configs/ls2080a_common.h | 2 +- include/configs/lx2160a_common.h | 2 +- 13 files changed, 201 insertions(+), 194 deletions(-) create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/spintable.S -- 2.20.1
[PATCH v2 01/13] armv8: layerscape: fix spin-table support
Spin tables are broken with bootefi. This is because - in contrast to
the booti call chain - there is no call to smp_kick_all_cpus(). Due to
this missing call the secondary CPUs are never released from their "wait
for interrupt state", see secondary_boot_func() in lowlevel.S.
Originally, this "wait for interrupt" is there to make sure, the spin
table is cleared before the secondary cores read it for the first time.
But the boot flow for the layerscape architecture is different from
that. The CPUs are release from their BootROM _after_ U-Boot's
spin-table is cleared, see fsl_layerscape_wake_seconday_cores() in mp.c.
Thus, there is no need to wait for this interrupt and no need for
kicking all cores on cpu_release. An atomic 64bit write to the
spin-table and a "sev" is sufficient.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 7 ---
arch/arm/cpu/armv8/fsl-layerscape/mp.c | 9 +
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 711ab87556..2a8d592cc5 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -474,13 +474,6 @@ ENTRY(secondary_boot_func)
mov x4, #1
str x4, [x11, #8] /* STATUS */
dsb sy
-#if defined(CONFIG_GICV3)
- gic_wait_for_interrupt_m x0
-#elif defined(CONFIG_GICV2)
- bl get_gic_offset
- mov x0, x1
-gic_wait_for_interrupt_m x0, w1
-#endif
slave_cpu:
wfe
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index 1ea887b331..e078d1cd37 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -277,11 +277,12 @@ int cpu_release(u32 nr, int argc, char *const argv[])
flush_dcache_range((unsigned long)table,
(unsigned long)table + SPIN_TABLE_ELEM_SIZE);
asm volatile("dsb st");
- smp_kick_all_cpus();/* only those with entry addr set will run */
+
/*
-* When the first release command runs, all cores are set to go. Those
-* without a valid entry address will be trapped by "wfe". "sev" kicks
-* them off to check the address again. When set, they continue to run.
+* The secondary CPUs polling the spin-table above for a non-zero
+* value. To save power "wfe" is called. Thus call "sev" here to
+* wake the CPUs and let them check the spin-table again (see
+* slave_cpu loop in lowlevel.S)
*/
asm volatile("sev");
--
2.20.1
[PATCH v2 05/13] armv8: layerscape: load function pointer using ADR
Don't use LDR to load a pointer to a function. This will generate a literal which cannot be relocated. Use ADR which is PC-relative and therefore can easily be relocated. Signed-off-by: Michael Walle --- arch/arm/cpu/armv8/fsl-layerscape/spintable.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S index d71ec13eaf..ac9c622aee 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S @@ -57,11 +57,11 @@ ENTRY(secondary_boot_func) * table (each elem is padded to 64 bytes) */ lsl x1, x10, #6 - ldr x0, =__spin_table + adr x0, __spin_table /* physical address of this cpus spin table element */ add x11, x1, x0 - ldr x0, =__real_cntfrq + adr x0, __real_cntfrq ldr x0, [x0] msr cntfrq_el0, x0 /* set with real frequency */ str x9, [x11, #16] /* LPID */ @@ -117,7 +117,7 @@ ENTRY(secondary_switch_to_el1) orr x10, x2, x1, lsl #2 /* x10 has LPID */ lsl x1, x10, #6 - ldr x0, =__spin_table + adr x0, __spin_table /* physical address of this cpus spin table element */ add x11, x1, x0 -- 2.20.1
[PATCH v2 08/13] armv8: layerscape: simplify get_spin_tbl_addr() calls
There is no need to cast around. Assign the address to the local
variable and use it.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/mp.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index d57b2898d4..c4692dcd85 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -76,7 +76,7 @@ int fsl_layerscape_wake_seconday_cores(void)
#endif
u32 cores, cpu_up_mask = 1;
int i, timeout = 10;
- u64 *table = get_spin_tbl_addr();
+ u64 *table;
#ifdef COUNTER_FREQUENCY_REAL
/* update for secondary cores */
@@ -89,6 +89,7 @@ int fsl_layerscape_wake_seconday_cores(void)
/* Clear spin table so that secondary processors
* observe the correct value after waking up from wfe.
*/
+ table = get_spin_tbl_addr();
memset(table, 0, CONFIG_MAX_CPUS*SPIN_TABLE_ELEM_SIZE);
flush_dcache_range((unsigned long)table,
(unsigned long)table +
@@ -185,9 +186,9 @@ static int is_pos_valid(unsigned int pos)
int is_core_online(u64 cpu_id)
{
- u64 *table;
+ u64 *table = get_spin_tbl_addr();
int pos = id_to_core(cpu_id);
- table = (u64 *)get_spin_tbl_addr() + pos * WORDS_PER_SPIN_TABLE_ENTRY;
+ table += pos * WORDS_PER_SPIN_TABLE_ENTRY;
return table[SPIN_TABLE_ELEM_STATUS_IDX] == 1;
}
@@ -233,18 +234,16 @@ static int core_to_pos(int nr)
int cpu_status(u32 nr)
{
- u64 *table;
+ u64 *table = get_spin_tbl_addr();
int pos;
if (nr == 0) {
- table = (u64 *)get_spin_tbl_addr();
printf("table base @ 0x%p\n", table);
} else {
pos = core_to_pos(nr);
if (pos < 0)
return -1;
- table = (u64 *)get_spin_tbl_addr() + pos *
- WORDS_PER_SPIN_TABLE_ENTRY;
+ table += pos * WORDS_PER_SPIN_TABLE_ENTRY;
printf("table @ 0x%p\n", table);
printf(" addr - 0x%016llx\n",
table[SPIN_TABLE_ELEM_ENTRY_ADDR_IDX]);
@@ -260,7 +259,7 @@ int cpu_status(u32 nr)
int cpu_release(u32 nr, int argc, char *const argv[])
{
u64 boot_addr;
- u64 *table = (u64 *)get_spin_tbl_addr();
+ u64 *table = get_spin_tbl_addr();
int pos;
pos = core_to_pos(nr);
--
2.20.1
[PATCH v2 09/13] armv8: layerscape: make wake_secondary_core_n() static
This function is not used outside the module. Make it static.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/mp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index c4692dcd85..753215add0 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -39,7 +39,7 @@ void update_os_arch_secondary_cores(uint8_t os_arch)
}
#ifdef CONFIG_FSL_LSCH3
-void wake_secondary_core_n(int cluster, int core, int cluster_cores)
+static void wake_secondary_core_n(int cluster, int core, int cluster_cores)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
struct ccsr_reset __iomem *rst = (void *)(CONFIG_SYS_FSL_RST_ADDR);
--
2.20.1
[PATCH v2 03/13] armv8: layerscape: properly use CPU_RELEASE_ADDR
The generic armv8 code already has support to bring up the secondary
cores. Thus, don't hardcode the jump in the layerscape lowlevel_init to
the spin table code; instead just return early and let the common armv8
code handle the jump. This way we can actually use the CPU_RELEASE_ADDR
feature.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 14 --
arch/arm/include/asm/arch-fsl-layerscape/mp.h | 1 -
include/configs/kontron_sl28.h| 2 +-
include/configs/ls1028a_common.h | 2 +-
include/configs/ls1043a_common.h | 2 +-
include/configs/ls1046a_common.h | 2 +-
include/configs/ls1088a_common.h | 2 +-
include/configs/ls2080a_common.h | 2 +-
include/configs/lx2160a_common.h | 2 +-
9 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 2a8d592cc5..d75013eb9c 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -208,8 +208,13 @@ ENTRY(lowlevel_init)
branch_if_master x0, x1, 2f
#if defined(CONFIG_MP) && defined(CONFIG_ARMV8_MULTIENTRY)
- ldr x0, =secondary_boot_func
- blr x0
+ /*
+* Formerly, here was a jump to secondary_boot_func, but we just
+* return early here and let the generic code in start.S handle
+* the jump to secondary_boot_func.
+*/
+ mov lr, x29 /* Restore LR */
+ ret
#endif
2:
@@ -421,6 +426,11 @@ ENDPROC(__asm_flush_l3_dcache)
#endif /* CONFIG_SYS_FSL_HAS_CCN504 */
#ifdef CONFIG_MP
+ .align 3
+ .global secondary_boot_addr
+secondary_boot_addr:
+ .quad secondary_boot_func
+
/* Keep literals not used by the secondary boot code outside it */
.ltorg
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
index 00aa91b0a2..623977651a 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
@@ -43,7 +43,6 @@ static inline int fsl_layerscape_wake_seconday_cores(void) {
return 0; }
#endif
void *get_spin_tbl_addr(void);
phys_addr_t determine_mp_bootpg(void);
-void secondary_boot_func(void);
int is_core_online(u64 cpu_id);
u32 cpu_pos_mask(void);
#endif
diff --git a/include/configs/kontron_sl28.h b/include/configs/kontron_sl28.h
index 70546d6f15..f97671bba1 100644
--- a/include/configs/kontron_sl28.h
+++ b/include/configs/kontron_sl28.h
@@ -32,7 +32,7 @@
#define CONFIG_SYS_MEMTEST_END 0x9fff
/* SMP */
-#define CPU_RELEASE_ADDR secondary_boot_func
+#define CPU_RELEASE_ADDR secondary_boot_addr
/* generic timer */
#define COUNTER_FREQUENCY 2500
diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h
index 33d9687eeb..540959d737 100644
--- a/include/configs/ls1028a_common.h
+++ b/include/configs/ls1028a_common.h
@@ -28,7 +28,7 @@
/*
* SMP Definitinos
*/
-#define CPU_RELEASE_ADDR secondary_boot_func
+#define CPU_RELEASE_ADDR secondary_boot_addr
/* Generic Timer Definitions */
#define COUNTER_FREQUENCY 2500/* 25MHz */
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 985f40412c..1c4bd5c68d 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -47,7 +47,7 @@
#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE
#define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
-#define CPU_RELEASE_ADDR secondary_boot_func
+#define CPU_RELEASE_ADDR secondary_boot_addr
/* Generic Timer Definitions */
#define COUNTER_FREQUENCY 2500/* 25MHz */
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index 24db23b3c3..176633da33 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -48,7 +48,7 @@
#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE
#define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
-#define CPU_RELEASE_ADDR secondary_boot_func
+#define CPU_RELEASE_ADDR secondary_boot_addr
/* Generic Timer Definitions */
#define COUNTER_FREQUENCY 2500/* 25MHz */
diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index a7373429ba..a9ca354851 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -48,7 +48,7 @@
/*
* SMP Definitinos
*/
-#define CPU_RELEASE_ADDR secondary_boot_func
+#define CPU_RELEASE_ADDR secondary_boot_addr
#ifdef CONFIG_PCI
#define CONFIG_CMD_PCI
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
ind
[PATCH v2 07/13] armv8: layerscape: remove determine_mp_bootpg()
Only the PowerPC architecture needs this function. Remove it.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/mp.c| 5 -
arch/arm/include/asm/arch-fsl-layerscape/mp.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index b5916ff3f3..d57b2898d4 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -23,11 +23,6 @@ void *get_spin_tbl_addr(void)
return &__spin_table;
}
-phys_addr_t determine_mp_bootpg(void)
-{
- return (phys_addr_t)&secondary_boot_code;
-}
-
void update_os_arch_secondary_cores(uint8_t os_arch)
{
u64 *table = get_spin_tbl_addr();
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
index 623977651a..3b470439bd 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
@@ -42,7 +42,6 @@ int fsl_layerscape_wake_seconday_cores(void);
static inline int fsl_layerscape_wake_seconday_cores(void) { return 0; }
#endif
void *get_spin_tbl_addr(void);
-phys_addr_t determine_mp_bootpg(void);
int is_core_online(u64 cpu_id);
u32 cpu_pos_mask(void);
#endif
--
2.20.1
[PATCH v2 10/13] armv8: layerscape: drop first .ltorg directive in spintable.S
Now that the spin table is in a separate module, this is no longer necessary. Drop it. Signed-off-by: Michael Walle --- arch/arm/cpu/armv8/fsl-layerscape/spintable.S | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S index a92f930e04..0e38cd009b 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S @@ -15,8 +15,6 @@ secondary_boot_addr: .quad secondary_boot_func - /* Keep literals not used by the secondary boot code outside it */ - .ltorg /* Using 64 bit alignment since the spin table is accessed as data */ .align 3 -- 2.20.1
[PATCH v2 12/13] armv8: layerscape: relocate spin table if EFI_LOADER is enabled
On ARM64, a 64kb region is reserved for the runtime services code.
Unfortunately, this code overlaps with the spin table code, which also
needs to be reserved. Thus now that the code is relocatable, allocate a
new page from EFI, copy the spin table code into it, update any pointers
to the old region and the start the secondary CPUs.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/mp.c | 36 ++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index d50c5a437b..bd85351705 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -79,6 +79,10 @@ int fsl_layerscape_wake_seconday_cores(void)
u32 cores, cpu_up_mask = 1;
int i, timeout = 10;
u64 *table;
+#ifdef CONFIG_EFI_LOADER
+ u64 reloc_addr = U32_MAX;
+ efi_status_t ret;
+#endif
#ifdef COUNTER_FREQUENCY_REAL
/* update for secondary cores */
@@ -87,6 +91,38 @@ int fsl_layerscape_wake_seconday_cores(void)
(unsigned long)&__real_cntfrq + 8);
#endif
+#ifdef CONFIG_EFI_LOADER
+ /*
+* EFI will reserve 64kb for its runtime services. This will probably
+* overlap with our spin table code, which is why we have to relocate
+* it.
+* Keep this after the __real_cntfrq update, so we have it when we
+* copy the complete section here.
+*/
+ ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
+EFI_RESERVED_MEMORY_TYPE,
+efi_size_in_pages(secondary_boot_code_size),
+&reloc_addr);
+ if (ret == EFI_SUCCESS) {
+ debug("Relocating spin table from %llx to %llx (size %lx)\n",
+ (u64)secondary_boot_code_start, reloc_addr,
+ secondary_boot_code_size);
+ memcpy((void *)reloc_addr, secondary_boot_code_start,
+ secondary_boot_code_size);
+ flush_dcache_range(reloc_addr,
+ reloc_addr + secondary_boot_code_size);
+
+ /* set new entry point for secondary cores */
+ secondary_boot_addr += (void *)reloc_addr -
+ secondary_boot_code_start;
+ flush_dcache_range((unsigned long)&secondary_boot_addr,
+ (unsigned long)&secondary_boot_addr + 8);
+
+ /* this will be used to reserve the memory */
+ secondary_boot_code_start = (void *)reloc_addr;
+ }
+#endif
+
cores = cpu_mask();
/* Clear spin table so that secondary processors
* observe the correct value after waking up from wfe.
--
2.20.1
[PATCH v2 13/13] armv8: layerscape: rework spin table
There are two issues: (1) The spin table doesn't convert the endianness of the jump address. Although there is code for it, the result isn't used at all (x0). (2) If something goes wrong, the function returns. But that doesn't make sense at all. Use the actual converted jump address as destination to fix. If there is an error, jump to a trap loop. And rearrange the code exception level switching code to make it smaller and clearer. This reduces the size of the spin table code section from 696 bytes to 424 bytes. If CONFIG_ARMV8_SWITCH_TO_EL1 the code size reduced from 696 bytes to 632 bytes. Signed-off-by: Michael Walle --- arch/arm/cpu/armv8/fsl-layerscape/spintable.S | 83 +-- 1 file changed, 23 insertions(+), 60 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S index f082e10231..363ded03e6 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S @@ -31,7 +31,7 @@ __spin_table: .space CONFIG_MAX_CPUS*SPIN_TABLE_ELEM_SIZE .align 2 -ENTRY(__secondary_boot_func) +__secondary_boot_func: /* * MPIDR_EL1 Fields: * MPIDR[1:0] = AFF0_CPUID <- Core ID (0,1) @@ -72,73 +72,36 @@ ENTRY(__secondary_boot_func) str x4, [x11, #8] /* STATUS */ dsb sy -slave_cpu: +1: wfe - ldr x0, [x11] - cbz x0, slave_cpu -#ifndef CONFIG_ARMV8_SWITCH_TO_EL1 + ldr x4, [x11] + cbz x4, 1b mrs x1, sctlr_el2 -#else - mrs x1, sctlr_el1 -#endif - tbz x1, #25, cpu_is_le - rev x0, x0 /* BE to LE conversion */ -cpu_is_le: - ldr x5, [x11, #24] - cbz x5, 1f - + tbz x1, #25, 2f + rev x4, x4 /* BE to LE conversion */ +2: + ldr x6, =ES_TO_AARCH64 #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - adr x4, secondary_switch_to_el1 - ldr x5, =ES_TO_AARCH64 -#else - ldr x4, [x11] - ldr x5, =ES_TO_AARCH32 + adr x5, 3f + switch_el x7, 0f, _dead_loop, _dead_loop +0: armv8_switch_to_el2_m x5, x6, x7 #endif - bl secondary_switch_to_el2 - -1: +3: + ldr x7, [x11, #24] /* ARCH_COMP */ + cbz x7, 4f + ldr x6, =ES_TO_AARCH32 +4: #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - adr x4, secondary_switch_to_el1 + switch_el x7, _dead_loop, 0f, _dead_loop +0: armv8_switch_to_el1_m x4, x6, x7 #else - ldr x4, [x11] + switch_el x7, 0f, _dead_loop, _dead_loop +0: armv8_switch_to_el2_m x4, x6, x7 #endif - ldr x5, =ES_TO_AARCH64 - bl secondary_switch_to_el2 - -ENDPROC(__secondary_boot_func) - -ENTRY(secondary_switch_to_el2) - switch_el x6, 1f, 0f, 0f -0: ret -1: armv8_switch_to_el2_m x4, x5, x6 -ENDPROC(secondary_switch_to_el2) - -ENTRY(secondary_switch_to_el1) - mrs x0, mpidr_el1 - ubfmx1, x0, #8, #15 - ubfmx2, x0, #0, #1 - orr x10, x2, x1, lsl #2 /* x10 has LPID */ - - lsl x1, x10, #6 - adr x0, __spin_table - /* physical address of this cpus spin table element */ - add x11, x1, x0 - - ldr x4, [x11] - - ldr x5, [x11, #24] - cbz x5, 2f - ldr x5, =ES_TO_AARCH32 - bl switch_to_el1 - -2: ldr x5, =ES_TO_AARCH64 - -switch_to_el1: - switch_el x6, 0f, 1f, 0f -0: ret -1: armv8_switch_to_el1_m x4, x5, x6 -ENDPROC(secondary_switch_to_el1) +_dead_loop: + wfe + b _dead_loop /* Ensure that the literals used by the secondary boot code are * assembled within it (this is required so that we can protect -- 2.20.1
[PATCH v9 1/2] i2c: i2c-cortina: added CAxxxx I2C support
From: Arthur Li
Add I2C controller support for Cortina Access CA SoCs
Signed-off-by: Arthur Li
Signed-off-by: Alex Nemirovsky
CC: Heiko Schocher
Reviewed-by: Heiko Schocher
---
Changes in v9:
- specially include bitops.h and delay.h which
were removed from common.h
Changes in v8:
- No code change
- Split out individual driver from Cortina Package 2 patch series
to help streamline acceptence into master
Changes in v7:
- Added additional description info in I2C KConfig
Changes in v6:
- Add I2C DT binding document
Changes in v4:
- Utilize standard I2C macros from
- Return ETIMEDOUT in funcs that can timeout
- Return i2c_xfer_init() result to caller of i2c_read() if it
fails within i2c_read() execution
- Fix misc. style guide conformance issues
- Use printf() to report i2c_xfer() runtime errors
instead of debug()
MAINTAINERS | 4 +
doc/device-tree-bindings/i2c/i2c-cortina.txt | 18 ++
drivers/i2c/Kconfig | 8 +
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-cortina.c| 346 +++
drivers/i2c/i2c-cortina.h| 87 +++
6 files changed, 464 insertions(+)
create mode 100644 doc/device-tree-bindings/i2c/i2c-cortina.txt
create mode 100644 drivers/i2c/i2c-cortina.c
create mode 100644 drivers/i2c/i2c-cortina.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8add9d4..ce70ca9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -181,6 +181,8 @@ F: drivers/gpio/cortina_gpio.c
F: drivers/watchdog/cortina_wdt.c
F: drivers/serial/serial_cortina.c
F: drivers/mmc/ca_dw_mmc.c
+F: drivers/i2c/i2c-cortina.c
+F: drivers/i2c/i2c-cortina.h
ARM/CZ.NIC TURRIS MOX SUPPORT
M: Marek Behun
@@ -732,6 +734,8 @@ F: drivers/gpio/cortina_gpio.c
F: drivers/watchdog/cortina_wdt.c
F: drivers/serial/serial_cortina.c
F: drivers/mmc/ca_dw_mmc.c
+F: drivers/i2c/i2c-cortina.c
+F: drivers/i2c/i2c-cortina.h
MIPS MSCC
M: Gregory CLEMENT
diff --git a/doc/device-tree-bindings/i2c/i2c-cortina.txt
b/doc/device-tree-bindings/i2c/i2c-cortina.txt
new file mode 100644
index 000..59d5235
--- /dev/null
+++ b/doc/device-tree-bindings/i2c/i2c-cortina.txt
@@ -0,0 +1,18 @@
+* I2C for Cortina platforms
+
+Required properties :
+- compatible : Must be "cortina,ca-i2c"
+- reg : Offset and length of the register set for the device
+
+Recommended properties :
+- clock-frequency : desired I2C bus clock frequency in Hz. If not specified,
+ default value is 10. Possible values are 10,
+ 40 and 100.
+
+Examples :
+
+ i2c: i2c@f4329120 {
+ compatible = "cortina,ca-i2c";
+ reg = <0x0 0xf4329120 0x28>;
+ clock-frequency = <40>;
+ };
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index f8b18de..b56e0d9 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -93,6 +93,14 @@ config SYS_I2C_CADENCE
Say yes here to select Cadence I2C Host Controller. This controller is
e.g. used by Xilinx Zynq.
+config SYS_I2C_CA
+ tristate "Cortina-Access I2C Controller"
+ depends on DM_I2C && CORTINA_PLATFORM
+ default n
+ help
+ Add support for the Cortina Access I2C host controller.
+ Say yes here to select Cortina-Access I2C Host Controller.
+
config SYS_I2C_DAVINCI
bool "Davinci I2C Controller"
depends on (ARCH_KEYSTONE || ARCH_DAVINCI)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 62935b7..d2b07ce 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SYS_I2C) += i2c_core.o
obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
+obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o
obj-$(CONFIG_SYS_I2C_DW) += designware_i2c.o
ifdef CONFIG_DM_PCI
diff --git a/drivers/i2c/i2c-cortina.c b/drivers/i2c/i2c-cortina.c
new file mode 100644
index 000..08b812a
--- /dev/null
+++ b/drivers/i2c/i2c-cortina.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020
+ * Arthur Li, Cortina Access, arthur...@cortina-access.com.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "i2c-cortina.h"
+
+static void set_speed(struct i2c_regs *regs, int i2c_spd)
+{
+ union ca_biw_cfg i2c_cfg;
+
+ i2c_cfg.wrd = readl(®s->i2c_cfg);
+ i2c_cfg.bf.core_en = 0;
+ writel(i2c_cfg.wrd, ®s->i2c_cfg);
+
+ switch (i2c_spd) {
+ case IC_SPEED_MODE_FAST_PLUS:
+ i2c_cfg.bf.prer = CORTINA_PER_IO_FREQ /
+ (5 * I2C_SPEED_FAST_PLUS_RATE) - 1;
+ break;
+
+ case IC_SPEED_MODE_STANDARD:
+ i2c_cfg.bf.prer = CORTINA_PER_IO_FREQ /
+ (5 * I2C
[PATCH v9 2/2] board: presidio-asic: Add I2C support
Add I2C board support for Cortina Access Presidio Engineering Board Signed-off-by: Alex Nemirovsky CC: Heiko Schocher Reviewed-by: Heiko Schocher --- Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v4: None configs/cortina_presidio-asic-emmc_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/cortina_presidio-asic-emmc_defconfig b/configs/cortina_presidio-asic-emmc_defconfig index e10008a..e45e23c 100644 --- a/configs/cortina_presidio-asic-emmc_defconfig +++ b/configs/cortina_presidio-asic-emmc_defconfig @@ -10,6 +10,7 @@ CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_BOOTDELAY=3 CONFIG_BOARD_EARLY_INIT_R=y CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y CONFIG_CMD_WDT=y @@ -24,6 +25,8 @@ CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" # CONFIG_NET is not set CONFIG_DM=y CONFIG_CORTINA_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_CA=y CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_CORTINA=y -- 2.7.4
[PATCH v2 11/13] armv8: layerscape: clean exported symbols in spintable.S
Add a new variable secondary_boot_code_start, which holds a pointer to
the start of the spin table code. This will help to relocate the code
section. While at it, move the size variable from the end to the
beginning so there is a common section for the variables. Remove any
other symbols.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 +++
arch/arm/cpu/armv8/fsl-layerscape/mp.c| 4 ++-
arch/arm/cpu/armv8/fsl-layerscape/spintable.S | 26 ++-
arch/arm/include/asm/arch-fsl-layerscape/mp.h | 6 ++---
4 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 9c7546028a..9c1e0c76f3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -54,7 +54,6 @@ void ft_fixup_cpu(void *blob)
fdt32_t *reg;
int addr_cells;
u64 val, core_id;
- size_t *boot_code_size = &(__secondary_boot_code_size);
u32 mask = cpu_pos_mask();
int off_prev = -1;
@@ -145,11 +144,11 @@ remove_psci_node:
"cpu", 4);
}
- fdt_add_mem_rsv(blob, (uintptr_t)&secondary_boot_code,
- *boot_code_size);
+ fdt_add_mem_rsv(blob, (uintptr_t)secondary_boot_code_start,
+ secondary_boot_code_size);
#if CONFIG_IS_ENABLED(EFI_LOADER)
- efi_add_memory_map((uintptr_t)&secondary_boot_code, *boot_code_size,
- EFI_RESERVED_MEMORY_TYPE);
+ efi_add_memory_map((uintptr_t)secondary_boot_code_start,
+ secondary_boot_code_size, EFI_RESERVED_MEMORY_TYPE);
#endif
}
#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index 753215add0..d50c5a437b 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -15,12 +15,14 @@
#include
#include "cpu.h"
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
void *get_spin_tbl_addr(void)
{
- return &__spin_table;
+ /* the spin table is at the beginning */
+ return secondary_boot_code_start;
}
void update_os_arch_secondary_cores(uint8_t os_arch)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S
b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S
index 0e38cd009b..f082e10231 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spintable.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spintable.S
@@ -10,23 +10,28 @@
#include
#include
- .align 3
- .global secondary_boot_addr
+.align 3
+.global secondary_boot_addr
secondary_boot_addr:
- .quad secondary_boot_func
+ .quad __secondary_boot_func
+
+.global secondary_boot_code_start
+secondary_boot_code_start:
+ .quad __secondary_boot_code_start
+.global secondary_boot_code_size
+secondary_boot_code_size:
+ .quad __secondary_boot_code_end - __secondary_boot_code_start
/* Using 64 bit alignment since the spin table is accessed as data */
.align 3
- .global secondary_boot_code
/* Secondary Boot Code starts here */
-secondary_boot_code:
- .global __spin_table
+__secondary_boot_code_start:
__spin_table:
.space CONFIG_MAX_CPUS*SPIN_TABLE_ELEM_SIZE
.align 2
-ENTRY(secondary_boot_func)
+ENTRY(__secondary_boot_func)
/*
* MPIDR_EL1 Fields:
* MPIDR[1:0] = AFF0_CPUID <- Core ID (0,1)
@@ -100,7 +105,7 @@ cpu_is_le:
ldr x5, =ES_TO_AARCH64
bl secondary_switch_to_el2
-ENDPROC(secondary_boot_func)
+ENDPROC(__secondary_boot_func)
ENTRY(secondary_switch_to_el2)
switch_el x6, 1f, 0f, 0f
@@ -146,8 +151,5 @@ ENDPROC(secondary_switch_to_el1)
.global __real_cntfrq
__real_cntfrq:
.quad COUNTER_FREQUENCY
- .globl __secondary_boot_code_size
- .type __secondary_boot_code_size, %object
/* Secondary Boot Code ends here */
-__secondary_boot_code_size:
- .quad .-secondary_boot_code
+__secondary_boot_code_end:
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
index 3b470439bd..faac8f1128 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
@@ -32,10 +32,10 @@
#define id_to_core(x) ((x & 3) | (x >> 6))
#ifndef __ASSEMBLY__
-extern u64 __spin_table[];
extern u64 __real_cntfrq;
-extern u64 *secondary_boot_code;
-extern size_t __secondary_boot_code_size;
+extern void *secondary_boot_addr;
+extern void *secondary_boot_code_start;
+extern size_t secondary_boot_code_size;
#ifdef CONFIG_MP
int fsl_layerscape_wake_seconday_cores(void);
#else
--
2.20.1
Re: [PATCH v8 1/2] spi: ca_sflash: Add CAxxxx SPI Flash Controller
> On Jun 1, 2020, at 9:45 AM, Jagan Teki wrote:
>
> On Fri, May 22, 2020 at 6:18 AM Alex Nemirovsky
> wrote:
>>
>> From: Pengpeng Chen
>>
>> Add SPI Flash controller driver for Cortina Access
>> CA SoCs
>>
>> Signed-off-by: Pengpeng Chen
>> Signed-off-by: Alex Nemirovsky
>> CC: Jagan Teki
>> CC: Vignesh R
>> CC: Tom Rini
>>
>> ---
>>
>> Changes in v8:
>> - No code change
>> - Split out individual driver from Cortina Package 2 patch series
>> to help streamline acceptence into master
>>
>> Changes in v7:
>> - Replace substring "OPCODE" with "OP" in MACROs to help
>> reduce code line lengths
>> - Replace substring "_MASK" with "_MSK" in MACROs to help
>> reduce code line lengths
>>
>> Changes in v5: None
>> Changes in v3:
>> - Fixup syntax issues related to checkpatch.pl cleanup
>>
>> MAINTAINERS | 8 +
>> drivers/spi/Kconfig | 8 +
>> drivers/spi/Makefile| 1 +
>> drivers/spi/ca_sflash.c | 576
>>
>> 4 files changed, 593 insertions(+)
>> create mode 100644 drivers/spi/ca_sflash.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8add9d4..57ce45e 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -181,6 +181,10 @@ F: drivers/gpio/cortina_gpio.c
>> F: drivers/watchdog/cortina_wdt.c
>> F: drivers/serial/serial_cortina.c
>> F: drivers/mmc/ca_dw_mmc.c
>> +F: drivers/i2c/i2c-cortina.c
>> +F: drivers/i2c/i2c-cortina.h
>> +F: drivers/led/led_cortina.c
>> +F: drivers/spi/ca_sflash.c
>>
>> ARM/CZ.NIC TURRIS MOX SUPPORT
>> M: Marek Behun
>> @@ -732,6 +736,10 @@ F: drivers/gpio/cortina_gpio.c
>> F: drivers/watchdog/cortina_wdt.c
>> F: drivers/serial/serial_cortina.c
>> F: drivers/mmc/ca_dw_mmc.c
>> +F: drivers/i2c/i2c-cortina.c
>> +F: drivers/i2c/i2c-cortina.h
>> +F: drivers/led/led_cortina.c
>
> These changes are unrelated to SPI, keep out of this patch.
will be corrected in v9
>
>> +F: drivers/spi/ca_sflash.c
>>
>> MIPS MSCC
>> M: Gregory CLEMENT
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index dccd5ea..09f2a2a 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -106,6 +106,14 @@ config BCMSTB_SPI
>> be used to access the SPI flash on platforms embedding this
>> Broadcom SPI core.
>>
>> +config CORTINA_SFLASH
>> + bool "Cortina-Access Serial Flash controller driver"
>> + depends on DM_SPI && SPI_MEM
>> + help
>> + Enable the Cortina-Access Serial Flash controller driver. This
>> driver
>> + can be used to access the SPI NOR/NAND flash on platforms
>> embedding this
>> + Cortina-Access IP core.
>> +
>> config CADENCE_QSPI
>>bool "Cadence QSPI driver"
>>help
>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>> index 6441694..5e53f11 100644
>> --- a/drivers/spi/Makefile
>> +++ b/drivers/spi/Makefile
>> @@ -25,6 +25,7 @@ obj-$(CONFIG_BCM63XX_SPI) += bcm63xx_spi.o
>> obj-$(CONFIG_BCMSTB_SPI) += bcmstb_spi.o
>> obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
>> obj-$(CONFIG_CF_SPI) += cf_spi.o
>> +obj-$(CONFIG_CORTINA_SFLASH) += ca_sflash.o
>> obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
>> obj-$(CONFIG_DESIGNWARE_SPI) += designware_spi.o
>> obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
>> diff --git a/drivers/spi/ca_sflash.c b/drivers/spi/ca_sflash.c
>> new file mode 100644
>> index 000..00af6bf
>> --- /dev/null
>> +++ b/drivers/spi/ca_sflash.c
>> @@ -0,0 +1,576 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Driver for Cortina SPI-FLASH Controller
>> + *
>> + * Copyright (C) 2020 Cortina Access Inc. All Rights Reserved.
>> + *
>> + * Author: PengPeng Chen
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +struct ca_sflash_regs {
>> + u32 idr;/* 0x00:Flash word ID Register */
>> + u32 tc; /* 0x04:Flash Timeout Counter Register */
>> + u32 sr; /* 0x08:Flash Status Register */
>> + u32 tr; /* 0x0C:Flash Type Register */
>> + u32 asr;/* 0x10:Flash ACCESS START/BUSY Register */
>> + u32 isr;/* 0x14:Flash Interrupt Status Register */
>> + u32 imr;/* 0x18:Flash Interrupt Mask Register */
>> + u32 fcr;/* 0x1C:NAND Flash FIFO Control Register */
>> + u32 ffsr; /* 0x20:Flash FIFO Status Register */
>> + u32 ffar; /* 0x24:Flash FIFO ADDRESS Register */
>> + u32 ffmar; /* 0x28:Flash FIFO MATCHING ADDRESS Register
>> */
>> + u32 ffdr; /* 0x2C:Flash FIFO Data Register */
>> + u32 ar; /* 0x30:Serial Flash Access Register */
>> + u32 ear;
Re: [PATCH v8 2/2] board: presidio-asic: Add SPI NOR support
> On Jun 1, 2020, at 9:48 AM, Jagan Teki wrote:
>
> On Fri, May 22, 2020 at 6:18 AM Alex Nemirovsky
> wrote:
>>
>> Add SPI NOR support for Cortina Access
>> Presidio Engineering Board
>>
>> Signed-off-by: Alex Nemirovsky
>> CC: Jagan Teki
>> CC: Vignesh R
>> CC: Tom Rini
>>
>> ---
>>
>> Changes in v8: None
>> Changes in v7: None
>> Changes in v5:
>> - NAND support removed from presidio-asic board DT.
>>
>> Changes in v3: None
>>
>> arch/arm/dts/ca-presidio-engboard.dts| 6 +--
>> board/cortina/presidio-asic/presidio.c | 16 ++-
>> configs/cortina_presidio-asic-spi-nand_defconfig | 48 +++
>> configs/cortina_presidio-asic-spi-nor_defconfig | 59
>>
>> 4 files changed, 124 insertions(+), 5 deletions(-)
>> create mode 100644 configs/cortina_presidio-asic-spi-nand_defconfig
>> create mode 100644 configs/cortina_presidio-asic-spi-nor_defconfig
>>
>> diff --git a/arch/arm/dts/ca-presidio-engboard.dts
>> b/arch/arm/dts/ca-presidio-engboard.dts
>> index c03dacc..34148b9 100644
>> --- a/arch/arm/dts/ca-presidio-engboard.dts
>> +++ b/arch/arm/dts/ca-presidio-engboard.dts
>> @@ -55,15 +55,13 @@
>>};
>>
>>sflash: sflash-controller@f4324000 {
>> - #address-cells = <2>;
>> - #size-cells = <1>;
>>compatible = "cortina,ca-sflash";
>>reg = <0x0 0xf4324000 0x50>;
>>reg-names = "sflash-regs";
>>flash@0 {
>>compatible = "jedec,spi-nor";
>> - spi-rx-bus-width = <1>;
>> - spi-max-frequency = <10800>;
>> + spi-rx-bus-width = <4>;
>> + spi-tx-bus-width = <4>;
>
> Unrelated change, please prepare separate patch.
SPI flash driver is bundled with a board specific integration file. Since the
SPI flash driver has yet to be accepted upstream
the previous board support DT for SPI-flash had no effect. Therefore this
change should not break anything as SPI flash driver
has yet to be active upstream.
>
>>};
>>};
>> };
>> diff --git a/board/cortina/presidio-asic/presidio.c
>> b/board/cortina/presidio-asic/presidio.c
>> index 3c132f1..883bd2e 100644
>> --- a/board/cortina/presidio-asic/presidio.c
>> +++ b/board/cortina/presidio-asic/presidio.c
>> @@ -16,7 +16,7 @@
>> #include
>> #include
>> #include
>> -
>> +#include
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> #define CA_PERIPH_BASE 0xE000UL
>> @@ -72,9 +72,23 @@ static noinline int invoke_psci_fn_smc(u64 function_id,
>> u64 arg0, u64 arg1,
>>return function_id;
>> }
>>
>> +#ifdef CONFIG_CORTINA_SFLASH
>> +static int init_sflash(void)
>> +{
>> + struct udevice *dev;
>> +
>> + uclass_first_device(UCLASS_SPI, &dev);
>
> I was wondering why SPI here is probing separately, we have sf to
> probe at run time?
Pengpeng,
please review and respond to this question.
[PATCH v9 2/2] board: presidio-asic: Add SPI NOR support
Add SPI NOR support for Cortina Access
Presidio Engineering Board
Signed-off-by: Alex Nemirovsky
CC: Jagan Teki
CC: Vignesh R
CC: Tom Rini
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v5:
- NAND support removed from presidio-asic board DT.
Changes in v3: None
arch/arm/dts/ca-presidio-engboard.dts| 6 +--
board/cortina/presidio-asic/presidio.c | 16 ++-
configs/cortina_presidio-asic-spi-nand_defconfig | 48 +++
configs/cortina_presidio-asic-spi-nor_defconfig | 59
4 files changed, 124 insertions(+), 5 deletions(-)
create mode 100644 configs/cortina_presidio-asic-spi-nand_defconfig
create mode 100644 configs/cortina_presidio-asic-spi-nor_defconfig
diff --git a/arch/arm/dts/ca-presidio-engboard.dts
b/arch/arm/dts/ca-presidio-engboard.dts
index c03dacc..34148b9 100644
--- a/arch/arm/dts/ca-presidio-engboard.dts
+++ b/arch/arm/dts/ca-presidio-engboard.dts
@@ -55,15 +55,13 @@
};
sflash: sflash-controller@f4324000 {
- #address-cells = <2>;
- #size-cells = <1>;
compatible = "cortina,ca-sflash";
reg = <0x0 0xf4324000 0x50>;
reg-names = "sflash-regs";
flash@0 {
compatible = "jedec,spi-nor";
- spi-rx-bus-width = <1>;
- spi-max-frequency = <10800>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
};
};
};
diff --git a/board/cortina/presidio-asic/presidio.c
b/board/cortina/presidio-asic/presidio.c
index 3c132f1..883bd2e 100644
--- a/board/cortina/presidio-asic/presidio.c
+++ b/board/cortina/presidio-asic/presidio.c
@@ -16,7 +16,7 @@
#include
#include
#include
-
+#include
DECLARE_GLOBAL_DATA_PTR;
#define CA_PERIPH_BASE 0xE000UL
@@ -72,9 +72,23 @@ static noinline int invoke_psci_fn_smc(u64 function_id, u64
arg0, u64 arg1,
return function_id;
}
+#ifdef CONFIG_CORTINA_SFLASH
+static int init_sflash(void)
+{
+ struct udevice *dev;
+
+ uclass_first_device(UCLASS_SPI, &dev);
+
+ return 0;
+}
+#endif
+
int board_early_init_r(void)
{
dcache_disable();
+#ifdef CONFIG_CORTINA_SFLASH
+ init_sflash();
+#endif
return 0;
}
diff --git a/configs/cortina_presidio-asic-spi-nand_defconfig
b/configs/cortina_presidio-asic-spi-nand_defconfig
new file mode 100644
index 000..515ad22
--- /dev/null
+++ b/configs/cortina_presidio-asic-spi-nand_defconfig
@@ -0,0 +1,48 @@
+CONFIG_ARM=y
+# CONFIG_SYS_ARCH_TIMER is not set
+CONFIG_TARGET_PRESIDIO_ASIC=y
+CONFIG_SYS_TEXT_BASE=0x0400
+CONFIG_ENV_SIZE=0x2
+CONFIG_DM_GPIO=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_IDENT_STRING="Presidio-SoC"
+CONFIG_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTDELAY=3
+CONFIG_LOGLEVEL=7
+CONFIG_BOARD_EARLY_INIT_R=y
+CONFIG_SYS_PROMPT="G3#"
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_WDT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_SMC=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard"
+# CONFIG_NET is not set
+CONFIG_DM=y
+CONFIG_CORTINA_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_CA=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_CORTINA=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_SPI_NAND=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DM_SERIAL=y
+CONFIG_CORTINA_UART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CORTINA_SFLASH=y
+CONFIG_WDT=y
+CONFIG_WDT_CORTINA=y
diff --git a/configs/cortina_presidio-asic-spi-nor_defconfig
b/configs/cortina_presidio-asic-spi-nor_defconfig
new file mode 100644
index 000..d7ecec3
--- /dev/null
+++ b/configs/cortina_presidio-asic-spi-nor_defconfig
@@ -0,0 +1,59 @@
+CONFIG_ARM=y
+# CONFIG_SYS_ARCH_TIMER is not set
+CONFIG_TARGET_PRESIDIO_ASIC=y
+CONFIG_SYS_TEXT_BASE=0x0400
+CONFIG_ENV_SIZE=0x2
+CONFIG_DM_GPIO=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_IDENT_STRING="Presidio-SoC"
+CONFIG_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_R=y
+CONFIG_SYS_PROMPT="G3#"
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_WDT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_SMC=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard"
+# CONFIG_NET is not set
+CONFIG_DM=y
+CONFIG_CORTINA_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_CA=y
+CONFIG_LED=y
+CONFIG_LED_CORTINA=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_CORTINA=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_ISSI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG
[PATCH v9 1/2] spi: ca_sflash: Add CAxxxx SPI Flash Controller
From: Pengpeng Chen
Add SPI Flash controller driver for Cortina Access
CA SoCs
Signed-off-by: Pengpeng Chen
Signed-off-by: Alex Nemirovsky
CC: Jagan Teki
CC: Vignesh R
CC: Tom Rini
---
Changes in v9:
- Clean up MAINTAINERS changes
Changes in v8:
- No code change
- Split out individual driver from Cortina Package 2 patch series
to help streamline acceptence into master
Changes in v7:
- Replace substring "OPCODE" with "OP" in MACROs to help
reduce code line lengths
- Replace substring "_MASK" with "_MSK" in MACROs to help
reduce code line lengths
Changes in v5: None
Changes in v3:
- Fixup syntax issues related to checkpatch.pl cleanup
MAINTAINERS | 2 +
drivers/spi/Kconfig | 8 +
drivers/spi/Makefile| 1 +
drivers/spi/ca_sflash.c | 576
4 files changed, 587 insertions(+)
create mode 100644 drivers/spi/ca_sflash.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8add9d4..a503f98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -181,6 +181,7 @@ F: drivers/gpio/cortina_gpio.c
F: drivers/watchdog/cortina_wdt.c
F: drivers/serial/serial_cortina.c
F: drivers/mmc/ca_dw_mmc.c
+F: drivers/spi/ca_sflash.c
ARM/CZ.NIC TURRIS MOX SUPPORT
M: Marek Behun
@@ -732,6 +733,7 @@ F: drivers/gpio/cortina_gpio.c
F: drivers/watchdog/cortina_wdt.c
F: drivers/serial/serial_cortina.c
F: drivers/mmc/ca_dw_mmc.c
+F: drivers/spi/ca_sflash.c
MIPS MSCC
M: Gregory CLEMENT
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index dccd5ea..09f2a2a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -106,6 +106,14 @@ config BCMSTB_SPI
be used to access the SPI flash on platforms embedding this
Broadcom SPI core.
+config CORTINA_SFLASH
+ bool "Cortina-Access Serial Flash controller driver"
+ depends on DM_SPI && SPI_MEM
+ help
+ Enable the Cortina-Access Serial Flash controller driver. This driver
+ can be used to access the SPI NOR/NAND flash on platforms embedding
this
+ Cortina-Access IP core.
+
config CADENCE_QSPI
bool "Cadence QSPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6441694..5e53f11 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_BCM63XX_SPI) += bcm63xx_spi.o
obj-$(CONFIG_BCMSTB_SPI) += bcmstb_spi.o
obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
obj-$(CONFIG_CF_SPI) += cf_spi.o
+obj-$(CONFIG_CORTINA_SFLASH) += ca_sflash.o
obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
obj-$(CONFIG_DESIGNWARE_SPI) += designware_spi.o
obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
diff --git a/drivers/spi/ca_sflash.c b/drivers/spi/ca_sflash.c
new file mode 100644
index 000..00af6bf
--- /dev/null
+++ b/drivers/spi/ca_sflash.c
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cortina SPI-FLASH Controller
+ *
+ * Copyright (C) 2020 Cortina Access Inc. All Rights Reserved.
+ *
+ * Author: PengPeng Chen
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct ca_sflash_regs {
+ u32 idr;/* 0x00:Flash word ID Register */
+ u32 tc; /* 0x04:Flash Timeout Counter Register */
+ u32 sr; /* 0x08:Flash Status Register */
+ u32 tr; /* 0x0C:Flash Type Register */
+ u32 asr;/* 0x10:Flash ACCESS START/BUSY Register */
+ u32 isr;/* 0x14:Flash Interrupt Status Register */
+ u32 imr;/* 0x18:Flash Interrupt Mask Register */
+ u32 fcr;/* 0x1C:NAND Flash FIFO Control Register */
+ u32 ffsr; /* 0x20:Flash FIFO Status Register */
+ u32 ffar; /* 0x24:Flash FIFO ADDRESS Register */
+ u32 ffmar; /* 0x28:Flash FIFO MATCHING ADDRESS Register */
+ u32 ffdr; /* 0x2C:Flash FIFO Data Register */
+ u32 ar; /* 0x30:Serial Flash Access Register */
+ u32 ear;/* 0x34:Serial Flash Extend Access Register */
+ u32 adr;/* 0x38:Serial Flash ADdress Register */
+ u32 dr; /* 0x3C:Serial Flash Data Register */
+ u32 tmr;/* 0x40:Serial Flash Timing Register */
+};
+
+/*
+ * FLASH_TYPE
+ */
+#define CA_FLASH_TR_PINBIT(15)
+#define CA_FLASH_TR_TYPE_MSK GENMASK(14, 12)
+#define CA_FLASH_TR_TYPE(tp) (((tp) << 12) & CA_FLASH_TR_TYPE_MSK)
+#define CA_FLASH_TR_WIDTH BIT(11)
+#define CA_FLASH_TR_SIZE_MSK GENMASK(10, 9)
+#define CA_FLASH_TR_SIZE(sz) (((sz) << 9) & CA_FLASH_TR_SIZE_MSK)
+
+/*
+ * FLASH_FLASH_ACCESS_START
+ */
+#define CA_FLASH_ASR_IND_START_EN BIT(1)
+
[PATCH] rockchip: Add delay after link-training
On at least the RockPro64, many cards will trip a synchronous abort when first accessing PCIe config space during bus scanning. A delay after link training allows some of these cards to function. Signed-off-by: Kurt Miller --- On the RockPro64, some pci cards trip a synchronous abort when scanning the pci bus. For example with HighPoint Rocket Raid 640L which is based on Marvell 88SE9230 I see this: => pci "Synchronous Abort" handler, esr 0x96000210 elr: 0022d034 lr : 0022cfd0 (reloc) elr: f4568034 lr : f4567fd0 x0 : 0010 x1 : f800 x2 : x3 : 0010 x4 : f2559290 x5 : x6 : 0001 x7 : f2559860 x8 : 0030 x9 : 0008 x10: 0010 x11: f251fd1c x12: 1421 x13: 1468 x14: f251fd4c x15: x16: 00060001 x17: 001f x18: f2532dc0 x19: f251fcd0 x20: 0001 x21: x22: 0001 x23: f45d4000 x24: x25: f45bc000 x26: x27: x28: f2541440 x29: f251fc20 Code: 54c1 35a5 93407c00 f9400081 (b8616800) Resetting CPU ... Adding a delay after link training works-around the problem. I added this delay to the OpenBSD rkpcie driver as well: https://github.com/openbsd/src/commit/9857dee3520d8ca5bec68538f4b0708d7e64fc87 HighPoint Rocket Raid 640L needs a 1.75 sec delay and Crossfield SAS9211-4i needs a 1 second delay, so I arbitrarily decided on 2 seconds. The delay work-around was originally discovered by nuumio: https://github.com/nuumio/linux-kernel/commit/5a65b17686002dc84d461bffa324a2cb68e67aee drivers/pci/pcie_rockchip.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/pci/pcie_rockchip.c b/drivers/pci/pcie_rockchip.c index 0edc2464a8..51cfbf6b18 100644 --- a/drivers/pci/pcie_rockchip.c +++ b/drivers/pci/pcie_rockchip.c @@ -288,6 +288,14 @@ static int rockchip_pcie_init_port(struct udevice *dev) goto err_power_off_phy; } + /* +* XXX: On at least the RockPro64, many cards will trip a +* synchronous abort when first accessing PCIe config space +* during bus scanning. A delay after link training allows +* some of these cards to function. +*/ + mdelay(2000); + /* Initialize Root Complex registers. */ writel(PCIE_LM_VENDOR_ROCKCHIP, priv->apb_base + PCIE_LM_VENDOR_ID); writel(PCI_CLASS_BRIDGE_PCI << 16, -- 2.26.2
[PATCH v2 2/2] board: presidio-asic: Add RAW Parallel NAND support
Add Parallel NAND CA support to Cortina Access Presidio Engineering Board support Signed-off-by: Alex Nemirovsky CC: Miquel Raynal CC: Simon Glass --- Changes in v2: None configs/cortina_presidio-asic-bch16_defconfig | 35 ++ configs/cortina_presidio-asic-bch24_defconfig | 36 +++ configs/cortina_presidio-asic-bch40_defconfig | 36 +++ configs/cortina_presidio-asic-bch8_defconfig | 36 +++ include/configs/presidio_asic.h | 15 +++ 5 files changed, 158 insertions(+) create mode 100644 configs/cortina_presidio-asic-bch16_defconfig create mode 100644 configs/cortina_presidio-asic-bch24_defconfig create mode 100644 configs/cortina_presidio-asic-bch40_defconfig create mode 100644 configs/cortina_presidio-asic-bch8_defconfig diff --git a/configs/cortina_presidio-asic-bch16_defconfig b/configs/cortina_presidio-asic-bch16_defconfig new file mode 100644 index 000..57ef98f --- /dev/null +++ b/configs/cortina_presidio-asic-bch16_defconfig @@ -0,0 +1,35 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +CONFIG_CORTINA_GPIO=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_CORTINA=y +CONFIG_DM_SERIAL=y +CONFIG_CORTINA_UART=y +CONFIG_WDT=y +CONFIG_WDT_CORTINA=y diff --git a/configs/cortina_presidio-asic-bch24_defconfig b/configs/cortina_presidio-asic-bch24_defconfig new file mode 100644 index 000..d22eae7 --- /dev/null +++ b/configs/cortina_presidio-asic-bch24_defconfig @@ -0,0 +1,36 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +CONFIG_CORTINA_GPIO=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_CORTINA=y +CONFIG_NAND_CORTINA_ECC_LEVEL=4 +CONFIG_DM_SERIAL=y +CONFIG_CORTINA_UART=y +CONFIG_WDT=y +CONFIG_WDT_CORTINA=y diff --git a/configs/cortina_presidio-asic-bch40_defconfig b/configs/cortina_presidio-asic-bch40_defconfig new file mode 100644 index 000..3c39415 --- /dev/null +++ b/configs/cortina_presidio-asic-bch40_defconfig @@ -0,0 +1,36 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +CONFIG_CORTINA_GPIO=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_CORTINA=y +CONFIG_NAND_CORTINA_ECC_LEVEL=5 +CONFIG_DM_SERIAL=y +CONFIG_CORTINA_UART=y +CONFIG_WDT=y +CONFIG_WDT_CORTINA=y diff --git a/configs/cortina_presidio-asic-bch8_defconfig b/configs/cortina_presidio-asic-bch8_defconfig new file mode 100644 index 000..8cda753 --- /dev/null +++ b/configs/cortina_presidio-asic-bch8_defconfig @@ -0,0 +1,36 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +CONFIG_CORTINA_GPIO=y
[PATCH v2 0/4] rockchip: rk3399: Add SPI boot
I have marked this series as v2, since the previous one has SPL SPI boot via different defconfig. Thanks to Hugh Cole-Baker for inputs about SPI boot image creation. Changes for v2: - same defconfig to support both MMC, SPI boot - add spi flash program document Any inputs? Jagan. Jagan Teki (4): Makefile: Drop to handle rkspi image type roc-rk3399-pc: Mark default env from SPI roc-rk3399-pc: Add SPI boot doc: rockchip: Document SPI flash program steps Makefile | 11 ++ arch/arm/dts/rk3399-roc-pc-u-boot.dtsi| 12 ++- configs/roc-pc-mezzanine-rk3399_defconfig | 3 +++ configs/roc-pc-rk3399_defconfig | 6 +- doc/board/rockchip/rockchip.rst | 26 ++- include/configs/roc-pc-rk3399.h | 4 6 files changed, 46 insertions(+), 16 deletions(-) -- 2.25.1
[PATCH v2 1/4] Makefile: Drop to handle rkspi image type
On rockchip platforms, SPI boot image creation is not straightforward like MMC boot image creation where former requires to specify tpl, spl in multimage format in mkimage, and later simply do a concatenate mkimaged-tpl with spl. On this note, let drop rkspi image type creation via kbuild and let inform via rockchip.rst Signed-off-by: Jagan Teki --- Makefile | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 3851dd9fa0..db3b6b9991 100644 --- a/Makefile +++ b/Makefile @@ -1438,22 +1438,15 @@ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE ifeq ($(CONFIG_ARCH_ROCKCHIP),y) -# rockchip image type -ifeq ($(CONFIG_SPL_SPI_LOAD),y) -ROCKCHIP_IMG_TYPE := rkspi -else -ROCKCHIP_IMG_TYPE := rksd -endif - # TPL + SPL ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy) -MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) +MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T rksd tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE $(call if_changed,mkimage) idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE $(call if_changed,cat) else -MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) +MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T rksd idbloader.img: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) endif -- 2.25.1
[PATCH v2 2/4] roc-rk3399-pc: Mark default env from SPI
Mark the default U-Boot environment as SPI flash since this is an on board flash device. Signed-off-by: Jagan Teki --- configs/roc-pc-rk3399_defconfig | 3 ++- include/configs/roc-pc-rk3399.h | 4 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index 76e76c160e..18c343f9f9 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 CONFIG_ROCKCHIP_RK3399=y CONFIG_TARGET_ROC_PC_RK3399=y @@ -24,7 +25,7 @@ CONFIG_CMD_TIME=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y diff --git a/include/configs/roc-pc-rk3399.h b/include/configs/roc-pc-rk3399.h index d4cbc3532e..59fe22289c 100644 --- a/include/configs/roc-pc-rk3399.h +++ b/include/configs/roc-pc-rk3399.h @@ -13,10 +13,6 @@ #include -#if defined(CONFIG_ENV_IS_IN_MMC) -# define CONFIG_SYS_MMC_ENV_DEV0 -#endif - #define SDRAM_BANK_SIZE(2UL << 30) #endif -- 2.25.1
[PATCH v2 3/4] roc-rk3399-pc: Add SPI boot
U-Boot TPL 2020.07-rc3-00090-gd4e919f927-dirty (Jun 01 2020 - 23:45:53)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 4 mhz 0, 1
lpddr4_set_rate: change freq to 8 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2020.07-rc3-00087-ga21e9fd385 (Jun 02 2020 - 00:09:45 +0530)
Trying to boot from MMC1
NOTICE: BL31: v2.2(release):
NOTICE: BL31: Built : 15:05:37, May 12 2020
U-Boot 2020.07-rc3-00087-ga21e9fd385 (Jun 02 2020 - 00:09:45 +0530)
SoC: Rockchip rk3399
Reset cause: POR
Model: Firefly ROC-RK3399-PC Board
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe32: 1, sdhci@fe33: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256
Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Model: Firefly ROC-RK3399-PC Board
Signed-off-by: Jagan Teki
---
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi| 12 +++-
configs/roc-pc-mezzanine-rk3399_defconfig | 3 +++
configs/roc-pc-rk3399_defconfig | 3 +++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index 141dd0b306..fc155e6903 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -12,7 +12,11 @@
};
chosen {
- u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
+ u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci,
&sdmmc;
+ };
+
+ config {
+ u-boot,spl-payload-offset = <0x6>; /* @ 384KB */
};
vcc_hub_en: vcc_hub_en-regulator {
@@ -40,6 +44,12 @@
vin-supply = <&vcc_vbus_typec0>;
};
+&spi1 {
+ spi_flash: flash@0 {
+ u-boot,dm-pre-reloc;
+ };
+};
+
&vdd_log {
regulator-min-microvolt = <43>;
regulator-init-microvolt = <95>;
diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig
b/configs/roc-pc-mezzanine-rk3399_defconfig
index 1c1539bcb9..4b98dd9cfc 100644
--- a/configs/roc-pc-mezzanine-rk3399_defconfig
+++ b/configs/roc-pc-mezzanine-rk3399_defconfig
@@ -7,12 +7,15 @@ CONFIG_TARGET_ROC_PC_RK3399=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_DEBUG_UART_BASE=0xFF1A
CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
CONFIG_DEBUG_UART=y
CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc-mezzanine.dtb"
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
CONFIG_SPL_STACK_R=y
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_SPI_LOAD=y
CONFIG_TPL=y
CONFIG_TPL_GPIO_SUPPORT=y
CONFIG_CMD_BOOTZ=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index 18c343f9f9..e5ff570b87 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -8,12 +8,15 @@ CONFIG_TARGET_ROC_PC_RK3399=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_DEBUG_UART_BASE=0xFF1A
CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
CONFIG_DEBUG_UART=y
CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb"
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
CONFIG_SPL_STACK_R=y
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_SPI_LOAD=y
CONFIG_TPL=y
CONFIG_TPL_GPIO_SUPPORT=y
CONFIG_CMD_BOOTZ=y
--
2.25.1
[PATCH v2 4/4] doc: rockchip: Document SPI flash program steps
Document SPI flash program steps for rockchip platforms.
Suggested-by: Hugh Cole-Baker
Signed-off-by: Jagan Teki
---
doc/board/rockchip/rockchip.rst | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 7b72fab496..76b228a046 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -162,6 +162,30 @@ Program the flash::
Note: for rockchip 32-bit platforms the U-Boot proper image
is u-boot-dtb.img
+SPI
+^^^
+
+Generating idbloader for SPI boot would require to input a multi image
+image format to mkimage tool instead of concerting (like for MMC boot).
+
+SPL-alone SPI boot image::
+
+./tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader.img
+
+TPL+SPL SPI boot image::
+
+./tools/mkimage -n rk3399 -T rkspi -d
tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader.img
+
+Copy SPI boot images into SD card and boot from SD::
+
+sf probe
+load mmc 1:1 $kernel_addr_r idbloader.img
+sf erase 0 +$filesize
+sf write $kernel_addr_r 0 ${filesize}
+load mmc 1:1 ${kernel_addr_r} u-boot.itb
+sf erase 0x6 +$filesize
+sf write $kernel_addr_r 0x6 ${filesize}
+
TODO
@@ -171,4 +195,4 @@ TODO
- Add missing SoC's with it boards list
.. Jagan Teki
-.. Sunday 24 May 2020 10:08:41 PM IST
+.. Tuesday 02 June 2020 12:18:57 AM IST
--
2.25.1
Re: [PATCH] rockchip: Add delay after link-training
On Tue, Jun 2, 2020 at 2:00 AM Kurt Miller wrote: > > On at least the RockPro64, many cards will trip a > synchronous abort when first accessing PCIe config space > during bus scanning. A delay after link training allows > some of these cards to function. Can you check does the SoC has external PCIe pwr-pin GPIO? I did see unstable SSD behavior on rock960 but fixed with this. https://github.com/radxa/u-boot/blob/stable-4.4-rockpi4/board/rockchip/evb_rk3399/evb-rk3399.c#L168
Re: [PATCH] RFC: tiny-dm: Proposal for using driver model in SPL
Hi Simon, On 26/5/20 15:39, Walter Lozano wrote: Hi Simon, On 25/5/20 18:40, Simon Glass wrote: Hi Tom, On Mon, 25 May 2020 at 14:57, Tom Rini wrote: On Mon, May 25, 2020 at 02:34:20PM -0600, Simon Glass wrote: Hi Tom, On Mon, 25 May 2020 at 13:47, Tom Rini wrote: On Mon, May 25, 2020 at 09:35:44AM -0600, Simon Glass wrote: This patch provides the documentation for a proposed enhancement to driver model to reduce overhead in SPL. The actual patches are not included here because they are based on some pending work by Walter Lozano which is not in final form. For now, the source tree is available at: https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working Comments welcome! So here's my worry. It's not clear, aside from the device tree, how much re-use of existing code we get with this. It feels like it might be fairly minimal. And at that point, are we not perhaps making too much work for ourselves compared with just excepting that there will need to be a place for non-abstracted-framework drivers? What do we do about TPL, when we get to the point of everything being converted to DM and as-needed tiny-DM but there's still TPL drivers? The reason we have SPL_FRAMEWORK as a symbol today is that we already had some SoCs/architectures (primarily PowerPC) that had "SPL" but it was very centric to the SoCs in question. The interface for example for mmc is: int spl_mmc_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) and neither part of that is inherently DM. So let it be MMC_TINY for the non-DM case and regular DM_MMC for the DM case. I wonder if we could clean that up code a little if we let it be separate. The interface for example for spi is: int spl_spi_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) and well, the same thing. Or maybe we can even push that up to the spi_flash_load() call. But my worry is that a different set of abstractions here are still going to bring us in more overhead than writing drivers for the functionality we need directly, and if we define what's allowed in this limited case well, that might be good enough. Some boards (e.g. x86) Need to read multiple things from the SPI flash (such as FSP binaries), so I still think we will want a generic reading interface. You could be right, but my hunch is that there is value in having things more generic and the cost should be minimal. The value is that hopefully writing a few C functions in the SPI driver will be enough to enable tiny SPI on an SoC, reusing much of the code in the driver (only the reading bits!). We won't need as much special-case code and an entirely different way of configuring these devices for TPL/SPL. It has been interesting digging into the Zephyr model. It's drivers are very basic and thus small. But there is still value in using the device tree to assemble things. Anyway I'm not really sure at this point. It is just a hunch. I don't think we can know all this until we have a bit more information. Perhaps with a board with SPI, MMC and serial converted we would get a better picture? I think it's absolutely the case that we'll have to convert something and see how it looks, then convert something else and see if it still looks good enough. At a high enough level there's not really too much of a difference between what it sounds like you're proposing and what I'm proposing. Possibly even in a progmatic way too. We have (I think anyhow) fairly static board configurations in this case so we don't so much need to "probe" for possible drivers be told what our device hierarchy is and to initialize what we're going to use. Yes, we may end up with special, separate code anyway, since if you end up refactoring the driver so much (and putting tiny-dm tentacles into it) that it becomes harder to maintain, it isn't a win. Basically I started out similar to what you are saying, with the idea of just direct calls into the driver (e.g. the driver implements serial_putc() and spi_read_flash()). But then I figured it is a very small overhead to retain some sort of driver model, so I thought I'd try that. I'll fiddle with this again in a week or so... Thanks for this proposal. I'm very interested in see where this implementation leads us, as I always felt that some work could be done in order to reduce the overhead of DM support in TPL/SPL. I'll review this work and hopefully come back to you with some comments. In the same sense, I feel that maybe we can add some additional intelligence to dtoc in order to produce a more customized code for TPL/SPL, maybe relaying in some custom stuff in u-boot.dtsi, but this is only a feeling. I've been checking your work and found it very interesting. Let me share some comments I really like the trade-off between size and features in this implementation and the way you get rid of not very useful data, such as strings and class overhead. I see that y
Re: [PATCH] rockchip: Add delay after link-training
On Tue, 2020-06-02 at 02:16 +0530, Jagan Teki wrote:
> On Tue, Jun 2, 2020 at 2:00 AM Kurt Miller wrote:
> >
> >
> > On at least the RockPro64, many cards will trip a
> > synchronous abort when first accessing PCIe config space
> > during bus scanning. A delay after link training allows
> > some of these cards to function.
> Can you check does the SoC has external PCIe pwr-pin GPIO?
>
> I did see unstable SSD behavior on rock960 but fixed with this.
> https://github.com/radxa/u-boot/blob/stable-4.4-rockpi4/board/rockchip/evb_rk3399/evb-rk3399.c#L168
The schematic has:
GPIO1_D0/TCPD_VBUS_SOURCE2_d ---L26>>PCIE_PWR
and arch/arm/dts/rk3399-rockpro64.dtsi has:
&pinctrl {
pcie {
pcie_pwr_en: pcie-pwr-en {
rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
};
Does that answer your question? I'm rather new at this so
I may need more guidance if I miss understood your question.
Thanks,
-Kurt
[PATCH v3 2/2] board: presidio-asic: Add RAW Parallel NAND support
Add Parallel NAND CA support to Cortina Access Presidio Engineering Board support Signed-off-by: Alex Nemirovsky CC: Miquel Raynal CC: Simon Glass --- Changes in v3: None Changes in v2: None configs/cortina_presidio-asic-bch16_defconfig | 35 ++ configs/cortina_presidio-asic-bch24_defconfig | 36 +++ configs/cortina_presidio-asic-bch40_defconfig | 36 +++ configs/cortina_presidio-asic-bch8_defconfig | 36 +++ include/configs/presidio_asic.h | 15 +++ 5 files changed, 158 insertions(+) create mode 100644 configs/cortina_presidio-asic-bch16_defconfig create mode 100644 configs/cortina_presidio-asic-bch24_defconfig create mode 100644 configs/cortina_presidio-asic-bch40_defconfig create mode 100644 configs/cortina_presidio-asic-bch8_defconfig diff --git a/configs/cortina_presidio-asic-bch16_defconfig b/configs/cortina_presidio-asic-bch16_defconfig new file mode 100644 index 000..57ef98f --- /dev/null +++ b/configs/cortina_presidio-asic-bch16_defconfig @@ -0,0 +1,35 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +CONFIG_CORTINA_GPIO=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_CORTINA=y +CONFIG_DM_SERIAL=y +CONFIG_CORTINA_UART=y +CONFIG_WDT=y +CONFIG_WDT_CORTINA=y diff --git a/configs/cortina_presidio-asic-bch24_defconfig b/configs/cortina_presidio-asic-bch24_defconfig new file mode 100644 index 000..d22eae7 --- /dev/null +++ b/configs/cortina_presidio-asic-bch24_defconfig @@ -0,0 +1,36 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +CONFIG_CORTINA_GPIO=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_CORTINA=y +CONFIG_NAND_CORTINA_ECC_LEVEL=4 +CONFIG_DM_SERIAL=y +CONFIG_CORTINA_UART=y +CONFIG_WDT=y +CONFIG_WDT_CORTINA=y diff --git a/configs/cortina_presidio-asic-bch40_defconfig b/configs/cortina_presidio-asic-bch40_defconfig new file mode 100644 index 000..3c39415 --- /dev/null +++ b/configs/cortina_presidio-asic-bch40_defconfig @@ -0,0 +1,36 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +CONFIG_CORTINA_GPIO=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_CORTINA=y +CONFIG_NAND_CORTINA_ECC_LEVEL=5 +CONFIG_DM_SERIAL=y +CONFIG_CORTINA_UART=y +CONFIG_WDT=y +CONFIG_WDT_CORTINA=y diff --git a/configs/cortina_presidio-asic-bch8_defconfig b/configs/cortina_presidio-asic-bch8_defconfig new file mode 100644 index 000..8cda753 --- /dev/null +++ b/configs/cortina_presidio-asic-bch8_defconfig @@ -0,0 +1,36 @@ +CONFIG_ARM=y +# CONFIG_SYS_ARCH_TIMER is not set +CONFIG_TARGET_PRESIDIO_ASIC=y +CONFIG_SYS_TEXT_BASE=0x0400 +CONFIG_ENV_SIZE=0x2 +CONFIG_ENV_OFFSET=0x40 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_IDENT_STRING="Presidio-SoC" +CONFIG_SHOW_BOOT_PROGRESS=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_SYS_PROMPT="G3#" +CONFIG_CMD_NAND=y +CONFIG_CMD_WDT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SMC=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard" +CONFIG_ENV_IS_IN_NAND=y +# CONFIG_NET is not set +CONFIG_DM=y +C
[PATCH v7 0/2] dm: uclass: don't assign aliased seq numbers
If there are aliases for an uclass, set the base for the "dynamically" allocated numbers next to the highest alias. The actual patch is 3, the first two patches will fix some breakage which would be introduced with patch 3. changes since v6: - added new patch to fix dev_read_alias_highest_id() changes since v5: - added test cases for usb dt node patch changes since v4: - new patch to fix the ethernet0 alias on Raspberry Pis. This has never been working, but wasn't a problem until recently. Patch 3 changes the allocation of the numbers and reserves possible aliases. changes since v3: - dev_read_alias_highest_id() is only available if CONFIG_OF_CONTROL is set. Thus added an additional condition "CONFIG_IS_ENABLED(OF_CONTROL)", thanks Simon. changes since v2: - adapt/new test cases, thanks Simon changes since v1: - move notice about superfluous commits from commit message to this section. - fix the comment style Michael Walle (3): usb: provide a device tree node to USB devices dm: core: fix dev_read_alias_highest_id() without libfdt dm: uclass: don't assign aliased seq numbers arch/sandbox/dts/test.dts | 13 +-- drivers/core/uclass.c | 21 +- drivers/usb/host/usb-uclass.c | 41 ++- include/configs/sandbox.h | 6 ++--- include/dm/read.h | 2 ++ test/dm/eth.c | 14 ++-- test/dm/test-fdt.c| 22 ++- test/dm/usb.c | 22 +++ 8 files changed, 113 insertions(+), 28 deletions(-) -- 2.20.1
[PATCH v7 2/3] dm: core: fix dev_read_alias_highest_id() without libfdt
If CONFIG_DM_DEV_READ_INLINE is set, dev_read_alias_highest_id() calls
libfdt_get_highest_id(). But this function is only available if we have
libfdt compiled in. If its not available return -1, which matches the
return code for no alias found.
This fixes the following error on omapl138_lcdk:
arm-linux-gnueabi-ld.bfd: drivers/built-in.o: in function
`dev_read_alias_highest_id':
/home/mw/repo/u-boot/include/dm/read.h:986: undefined reference to
`fdtdec_get_alias_highest_id'
Signed-off-by: Michael Walle
---
include/dm/read.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dm/read.h b/include/dm/read.h
index b952551d55..1c1bc3702f 100644
--- a/include/dm/read.h
+++ b/include/dm/read.h
@@ -983,6 +983,8 @@ static inline u64 dev_translate_dma_address(const struct
udevice *dev,
static inline int dev_read_alias_highest_id(const char *stem)
{
+ if (!CONFIG_IS_ENABLED(OF_LIBFDT))
+ return -1;
return fdtdec_get_alias_highest_id(gd->fdt_blob, stem);
}
--
2.20.1
[PATCH v7 1/3] usb: provide a device tree node to USB devices
It is possible to specify a device tree node for an USB device. This is
useful if you have a static USB setup and want to use aliases which
point to these nodes, like on the Raspberry Pi.
The nodes are matched against their hub port number, the compatible
strings are not matched for now.
Signed-off-by: Michael Walle
Reviewed-by: Marek Vasut
Reviewed-by: Simon Glass
---
arch/sandbox/dts/test.dts | 9
drivers/usb/host/usb-uclass.c | 41 ++-
test/dm/usb.c | 22 +++
3 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 5ce5e28476..b9255e4593 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -810,6 +810,8 @@
hub {
compatible = "usb-hub";
usb,device-class = <9>;
+ #address-cells = <1>;
+ #size-cells = <0>;
hub-emul {
compatible = "sandbox,usb-hub";
#address-cells = <1>;
@@ -838,6 +840,13 @@
};
};
+
+ usbstor@1 {
+ reg = <1>;
+ };
+ usbstor@3 {
+ reg = <3>;
+ };
};
};
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index cb79dfbbd5..f42c0625cb 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -494,6 +494,35 @@ static int usb_match_one_id(struct usb_device_descriptor
*desc,
return usb_match_one_id_intf(desc, int_desc, id);
}
+static ofnode usb_get_ofnode(struct udevice *hub, int port)
+{
+ ofnode node;
+ u32 reg;
+
+ if (!dev_has_of_node(hub))
+ return ofnode_null();
+
+ /*
+* The USB controller and its USB hub are two different udevices,
+* but the device tree has only one node for both. Thus we are
+* assigning this node to both udevices.
+* If port is zero, the controller scans its root hub, thus we
+* are using the same ofnode as the controller here.
+*/
+ if (!port)
+ return dev_ofnode(hub);
+
+ ofnode_for_each_subnode(node, dev_ofnode(hub)) {
+ if (ofnode_read_u32(node, "reg", ®))
+ continue;
+
+ if (reg == port)
+ return node;
+ }
+
+ return ofnode_null();
+}
+
/**
* usb_find_and_bind_driver() - Find and bind the right USB driver
*
@@ -502,13 +531,14 @@ static int usb_match_one_id(struct usb_device_descriptor
*desc,
static int usb_find_and_bind_driver(struct udevice *parent,
struct usb_device_descriptor *desc,
struct usb_interface_descriptor *iface,
- int bus_seq, int devnum,
+ int bus_seq, int devnum, int port,
struct udevice **devp)
{
struct usb_driver_entry *start, *entry;
int n_ents;
int ret;
char name[30], *str;
+ ofnode node = usb_get_ofnode(parent, port);
*devp = NULL;
debug("%s: Searching for driver\n", __func__);
@@ -533,8 +563,8 @@ static int usb_find_and_bind_driver(struct udevice *parent,
* find another driver. For now this doesn't seem
* necesssary, so just bind the first match.
*/
- ret = device_bind(parent, drv, drv->name, NULL, -1,
- &dev);
+ ret = device_bind_ofnode(parent, drv, drv->name, NULL,
+node, &dev);
if (ret)
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
@@ -651,9 +681,10 @@ int usb_scan_device(struct udevice *parent, int port,
if (ret) {
if (ret != -ENOENT)
return ret;
- ret = usb_find_and_bind_driver(parent, &udev->descriptor, iface,
+ ret = usb_find_and_bind_driver(parent, &udev->descriptor,
+ iface,
udev->controller_dev->seq,
- udev->devnum, &dev);
+ udev->devnum, port, &dev);
if (ret)
return ret;
created = true;
diff --git a/test/dm/usb.c b/test/dm/usb.c
index a25c2c1482..b273a515ef 100644
--- a/test/dm/usb.c
+++ b/test/dm/usb.c
@@ -78,6 +78,28 @@ static int dm_test_usb_multi(st
[PATCH v7 3/3] dm: uclass: don't assign aliased seq numbers
If there are aliases for an uclass, set the base for the "dynamically"
allocated numbers next to the highest alias.
Please note, that this might lead to holes in the sequences, depending
on the device tree. For example if there is only an alias "ethernet1",
the next device seq number would be 2.
In particular this fixes a problem with boards which are using ethernet
aliases but also might have network add-in cards like the E1000. If the
board is started with the add-in card and depending on the order of the
drivers, the E1000 might occupy the first ethernet device and mess up
all the hardware addresses, because the devices are now shifted by one.
Also adapt the test cases to the new handling and add test cases
checking the holes in the seq numbers.
Signed-off-by: Michael Walle
Reviewed-by: Alex Marginean
Tested-by: Alex Marginean
Acked-by: Vladimir Oltean
Reviewed-by: Simon Glass
Tested-by: Michal Simek [on zcu102-revA]
---
arch/sandbox/dts/test.dts | 4 ++--
drivers/core/uclass.c | 21 +++--
include/configs/sandbox.h | 6 +++---
test/dm/eth.c | 14 +++---
test/dm/test-fdt.c| 22 +-
5 files changed, 44 insertions(+), 23 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index b9255e4593..a6e2bfd082 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -23,8 +23,8 @@
pci0 = &pci0;
pci1 = &pci1;
pci2 = &pci2;
- remoteproc1 = &rproc_1;
- remoteproc2 = &rproc_2;
+ remoteproc0 = &rproc_1;
+ remoteproc1 = &rproc_2;
rtc0 = &rtc_0;
rtc1 = &rtc_1;
spi0 = "/spi@0";
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 2ab419cfe4..c3f1b73cd6 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -689,13 +689,14 @@ int uclass_unbind_device(struct udevice *dev)
int uclass_resolve_seq(struct udevice *dev)
{
+ struct uclass *uc = dev->uclass;
+ struct uclass_driver *uc_drv = uc->uc_drv;
struct udevice *dup;
- int seq;
+ int seq = 0;
int ret;
assert(dev->seq == -1);
- ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, dev->req_seq,
- false, &dup);
+ ret = uclass_find_device_by_seq(uc_drv->id, dev->req_seq, false, &dup);
if (!ret) {
dm_warn("Device '%s': seq %d is in use by '%s'\n",
dev->name, dev->req_seq, dup->name);
@@ -707,9 +708,17 @@ int uclass_resolve_seq(struct udevice *dev)
return ret;
}
- for (seq = 0; seq < DM_MAX_SEQ; seq++) {
- ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, seq,
- false, &dup);
+ if (CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(DM_SEQ_ALIAS) &&
+ (uc_drv->flags & DM_UC_FLAG_SEQ_ALIAS)) {
+ /*
+* dev_read_alias_highest_id() will return -1 if there no
+* alias. Thus we can always add one.
+*/
+ seq = dev_read_alias_highest_id(uc_drv->name) + 1;
+ }
+
+ for (; seq < DM_MAX_SEQ; seq++) {
+ ret = uclass_find_device_by_seq(uc_drv->id, seq, false, &dup);
if (ret == -ENODEV)
break;
if (ret)
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 484a15df79..a2c9811eca 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -95,9 +95,9 @@
#endif
#define SANDBOX_ETH_SETTINGS "ethaddr=00:00:11:22:33:44\0" \
- "eth1addr=00:00:11:22:33:45\0" \
- "eth3addr=00:00:11:22:33:46\0" \
- "eth5addr=00:00:11:22:33:47\0" \
+ "eth3addr=00:00:11:22:33:45\0" \
+ "eth5addr=00:00:11:22:33:46\0" \
+ "eth6addr=00:00:11:22:33:47\0" \
"ipaddr=1.2.3.4\0"
#define MEM_LAYOUT_ENV_SETTINGS \
diff --git a/test/dm/eth.c b/test/dm/eth.c
index 1fddcaabb0..b58c9640a2 100644
--- a/test/dm/eth.c
+++ b/test/dm/eth.c
@@ -48,7 +48,7 @@ static int dm_test_eth_alias(struct unit_test_state *uts)
ut_assertok(net_loop(PING));
ut_asserteq_str("eth@10002000", env_get("ethact"));
- env_set("ethact", "eth1");
+ env_set("ethact", "eth6");
ut_assertok(net_loop(PING));
ut_asserteq_str("eth@10004000", env_get("ethact"));
@@ -105,7 +105,7 @@ static int dm_test_eth_act(struct unit_test_state *uts)
const char *ethname[DM_TEST_ETH_NUM] = {"eth@10002000", "eth@10003000",
"sbe5", "eth@10004000"};
const ch
Re: [PATCH 2/3] x86: baytrail: acpi: Replace _ADR() by _UID() in description of PCI host bridge
On Mon, Jun 1, 2020 at 12:15 PM Bin Meng wrote: > > PCI Firmware specification requires _UID() and doesn't require _ADR() > to be set. Replace latter by former. This fixes the following warning > reported by ACPICA 20200430: > > Warning 3073 - Multiple types (Device object requires either a _HID > or _ADR, but not both) > > Signed-off-by: Bin Meng > --- > > arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > applied to u-boot-x86, thanks!
Re: [PATCH 3/3] x86: quark: acpi: Replace _ADR() by _UID() in description of PCI host bridge
On Mon, Jun 1, 2020 at 4:42 PM Andy Shevchenko wrote: > > On Sun, May 31, 2020 at 09:15:15PM -0700, Bin Meng wrote: > > PCI Firmware specification requires _UID() and doesn't require _ADR() > > to be set. Replace latter by former. This fixes the following warning > > reported by ACPICA 20200430: > > > > Warning 3073 - Multiple types (Device object requires either a _HID > > or _ADR, but not both) > > > > For all three: > Reviewed-by: Andy Shevchenko > > > Signed-off-by: Bin Meng > > --- > > > > arch/x86/include/asm/arch-quark/acpi/southcluster.asl | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > applied to u-boot-x86, thanks!
Re: [PATCH 1/3] x86: baytrail: acpi: Create buffers outside of the methods
On Mon, Jun 1, 2020 at 12:15 PM Bin Meng wrote: > > Create buffers outside of the methods as ACPICA 20200430 complains > about this: > > Remark 2173 - Creation of named objects within a method is highly > inefficient, use globals or method local variables instead > (\_SB.PCI0.LPCB.IURT._CRS) > > Signed-off-by: Bin Meng > --- > > arch/x86/include/asm/arch-baytrail/acpi/lpc.asl | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) > applied to u-boot-x86, thanks!
Please pull u-boot-x86
Hi Tom, This PR includes the following x86 changes for v2020.07: - Corrected some FSP-M/FSP-S settings for Chromebook Coral - ICH SPI driver and mrccache fixes for obtaining the SPI memory map - Fixed various warnings generated by latest version IASL when compiling ACPI tables The following changes since commit 9452b7496f8b85ca3bdda1014495df1a6235a8de: Merge tag 'u-boot-rockchip-20200531' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip (2020-05-31 20:07:39 -0400) are available in the git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-x86 for you to fetch changes up to 95cfa1d46c61461bdadb195799a205b48b907a5e: x86: quark: acpi: Replace _ADR() by _UID() in description of PCI host bridge (2020-06-02 09:16:13 +0800) Andy Shevchenko (4): x86: tangier: acpi: Create buffers outside of the methods x86: tangier: acpi: Replace _ADR() by _UID() in description of PCI host bridge x86: tangier: acpi: Drop _ADR() where _HID() is present x86: tangier: acpi: Drop _HID() where enumerated by _ADR() Bin Meng (3): x86: baytrail: acpi: Create buffers outside of the methods x86: baytrail: acpi: Replace _ADR() by _UID() in description of PCI host bridge x86: quark: acpi: Replace _ADR() by _UID() in description of PCI host bridge Simon Glass (9): x86: spi: Add a way to access the SPI mapping via registers x86: spi: Rewrite logic for obtaining the SPI memory map x86: spl: Print the error on SPL failure x86: mrccache: Allow use before driver model is active x86: coral: Correct some FSP-M settings x86: apl: Add hex offsets for registers in FSP-M x86: coral: Correct some FSP-S settings x86: apl: Add hex offsets for registers in FSP-S x86: minnowmax: Add support for Winbond flash arch/x86/cpu/intel_common/fast_spi.c | 19 ++- arch/x86/dts/chromebook_coral.dts| 15 --- arch/x86/include/asm/arch-apollolake/fsp/fsp_m_upd.h | 17 +++-- arch/x86/include/asm/arch-apollolake/fsp/fsp_s_upd.h | 72 arch/x86/include/asm/arch-baytrail/acpi/lpc.asl | 24 arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl | 2 +- arch/x86/include/asm/arch-quark/acpi/southcluster.asl| 2 +- arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 99 ++- arch/x86/include/asm/fast_spi.h | 19 +++ arch/x86/include/asm/mrccache.h | 15 --- arch/x86/lib/mrccache.c | 35 +-- arch/x86/lib/spl.c | 4 ++-- board/intel/minnowmax/Kconfig| 3 +++ drivers/spi/ich.c| 103 --- 14 files changed, 314 insertions(+), 115 deletions(-) Regards, Bin
Re: [PATCH] rockchip: Add delay after link-training
Hi Kurt, On 2020/6/2 上午4:30, Kurt Miller wrote: On at least the RockPro64, many cards will trip a synchronous abort when first accessing PCIe config space during bus scanning. A delay after link training allows some of these cards to function. Signed-off-by: Kurt Miller --- On the RockPro64, some pci cards trip a synchronous abort when scanning the pci bus. For example with HighPoint Rocket Raid 640L which is based on Marvell 88SE9230 I see this: => pci "Synchronous Abort" handler, esr 0x96000210 elr: 0022d034 lr : 0022cfd0 (reloc) elr: f4568034 lr : f4567fd0 x0 : 0010 x1 : f800 x2 : x3 : 0010 x4 : f2559290 x5 : x6 : 0001 x7 : f2559860 x8 : 0030 x9 : 0008 x10: 0010 x11: f251fd1c x12: 1421 x13: 1468 x14: f251fd4c x15: x16: 00060001 x17: 001f x18: f2532dc0 x19: f251fcd0 x20: 0001 x21: x22: 0001 x23: f45d4000 x24: x25: f45bc000 x26: x27: x28: f2541440 x29: f251fc20 Code: 54c1 35a5 93407c00 f9400081 (b8616800) Resetting CPU ... Adding a delay after link training works-around the problem. I added this delay to the OpenBSD rkpcie driver as well: https://github.com/openbsd/src/commit/9857dee3520d8ca5bec68538f4b0708d7e64fc87 HighPoint Rocket Raid 640L needs a 1.75 sec delay and Crossfield SAS9211-4i needs a 1 second delay, so I arbitrarily decided on 2 seconds. The delay work-around was originally discovered by nuumio: https://github.com/nuumio/linux-kernel/commit/5a65b17686002dc84d461bffa324a2cb68e67aee drivers/pci/pcie_rockchip.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/pci/pcie_rockchip.c b/drivers/pci/pcie_rockchip.c index 0edc2464a8..51cfbf6b18 100644 --- a/drivers/pci/pcie_rockchip.c +++ b/drivers/pci/pcie_rockchip.c @@ -288,6 +288,14 @@ static int rockchip_pcie_init_port(struct udevice *dev) goto err_power_off_phy; } + /* +* XXX: On at least the RockPro64, many cards will trip a +* synchronous abort when first accessing PCIe config space +* during bus scanning. A delay after link training allows +* some of these cards to function. +*/ + mdelay(2000); I don't understand what kind of delay for init needs 2 Seconds, root cause will preferred. Thanks, - Kever + /* Initialize Root Complex registers. */ writel(PCIE_LM_VENDOR_ROCKCHIP, priv->apb_base + PCIE_LM_VENDOR_ID); writel(PCI_CLASS_BRIDGE_PCI << 16,
Re: Thoughts on code line length
Hi Tom, Didn't check the update for checkpatch.pl, but my point for code line length is: Warning is necessary for 80 characters exceed, so author and reviewer can notice it, but it's case by case, if this is reasonable, it's OK to exceed 80 characters for better readability. Thanks, - Kever On 2020/6/1 下午9:23, Tom Rini wrote: Hey all, As I see tech sites are noting that Linus has changed the kernel's code style to no longer be so strict about 80 character line width, I figured I should say something here given how much we follow the Linux kernel anyhow. Given that we've long told people to ignore checkpatch for dts files, and to not split error messages anyhow, and that it's more about "does the code read well", I think this is a good change that we'll pick up with our next re-sync of checkpatch.pl. I figured over the weekend I would grab Simon's checkpatch series today, but I'll wait a day or two and sync it to v5.7 release before grabbing. I think this is a good change overall given the amount of times I've had to reduce readability slightly (and use odd variable names) to not exceed 80 characters on a line by just a few.
Re: [PATCH 02/13] efi_loader: image_loader: add a check against certificate type of authenticode
Heinrich,
On Fri, May 29, 2020 at 12:37:26PM +0200, Heinrich Schuchardt wrote:
> On 5/29/20 8:41 AM, AKASHI Takahiro wrote:
> > UEFI specification requires that we shall support three type of
> > certificates of authenticode in PE image:
> > WIN_CERT_TYPE_EFI_GUID with the guid, EFI_CERT_TYPE_PCKS7_GUID
> > WIN_CERT_TYPE_PKCS_SIGNED_DATA
> > WIN_CERT_TYPE_EFI_PKCS1_15
> >
> > As EDK2 does, we will support the first two that are pkcs7 SignedData.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > lib/efi_loader/efi_image_loader.c | 55 ---
> > 1 file changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_image_loader.c
> > b/lib/efi_loader/efi_image_loader.c
> > index 7f35b1e58fe5..a13ba3692ec2 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -375,7 +375,7 @@ bool efi_image_parse(void *efi, size_t len, struct
> > efi_image_regions **regp,
> > }
> >
> > /* Return Certificates Table */
> > - if (authsz) {
> > + if (authsz > 0) {
>
> authsz is unsigned. We should avoid superfluous comparisons with 0.
Okay. I was a bit confused here.
> > if (len < authoff + authsz) {
> > debug("%s: Size for auth too large: %u >= %zu\n",
> > __func__, authsz, len - authoff);
> > @@ -480,8 +480,8 @@ static bool efi_image_authenticate(void *efi, size_t
> > efi_size)
> > struct pkcs7_message *msg = NULL;
> > struct efi_signature_store *db = NULL, *dbx = NULL;
> > struct x509_certificate *cert = NULL;
> > - void *new_efi = NULL;
> > - size_t new_efi_size;
> > + void *new_efi = NULL, *auth, *wincerts_end;
> > + size_t new_efi_size, auth_size;
> > bool ret = false;
> >
> > if (!efi_secure_boot_enabled())
> > @@ -530,20 +530,51 @@ static bool efi_image_authenticate(void *efi, size_t
> > efi_size)
> > }
> >
> > /* go through WIN_CERTIFICATE list */
> > - for (wincert = wincerts;
> > -(void *)wincert < (void *)wincerts + wincerts_len;
> > + for (wincert = wincerts, wincerts_end = (void *)wincerts + wincerts_len;
> > +(void *)wincert < wincerts_end;
>
> Adding to (void *) is not defined in the C spec (though gcc treats it
> according to your intention). Please, use (u8 *) if you want to add byte
> lengths.
Okay.
> > wincert = (void *)wincert + ALIGN(wincert->dwLength, 8)) {
> > - if (wincert->dwLength < sizeof(*wincert)) {
> > - debug("%s: dwLength too small: %u < %zu\n",
> > - __func__, wincert->dwLength, sizeof(*wincert));
> > - goto err;
> > + if ((void *)wincert + sizeof(*wincert) >= wincerts_end)
> > + break;
> > +
> > + if (wincert->dwLength <= sizeof(*wincert)) {
> > + debug("dwLength too small: %u < %zu\n",
> > + wincert->dwLength, sizeof(*wincert));
> > + continue;
> > }
> > - msg = pkcs7_parse_message((void *)wincert + sizeof(*wincert),
> > - wincert->dwLength - sizeof(*wincert));
> > +
> > + debug("WIN_CERTIFICATE_TYPE: 0x%x\n",
> > + wincert->wCertificateType);
>
> Should this EFI_PRINT()?
Okay, I will replace all.
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > +
> > + auth = (void *)wincert + sizeof(*wincert);
> > + auth_size = wincert->dwLength - sizeof(*wincert);
> > + if (wincert->wCertificateType == WIN_CERT_TYPE_EFI_GUID) {
> > + if (auth + sizeof(efi_guid_t) >= wincerts_end)
> > + break;
> > +
> > + if (auth_size <= sizeof(efi_guid_t)) {
> > + debug("dwLength too small: %u < %zu\n",
> > + wincert->dwLength, sizeof(*wincert));
> > + continue;
> > + }
> > + if (guidcmp(auth, &efi_guid_cert_type_pkcs7)) {
> > + debug("Certificate type not supported: %pUl\n",
> > + auth);
> > + continue;
> > + }
> > +
> > + auth += sizeof(efi_guid_t);
> > + auth_size -= sizeof(efi_guid_t);
> > + } else if (wincert->wCertificateType
> > + != WIN_CERT_TYPE_PKCS_SIGNED_DATA) {
> > + debug("Certificate type not supported\n");
> > + continue;
> > + }
> > +
> > + msg = pkcs7_parse_message(auth, auth_size);
> > if (IS_ERR(msg)) {
> > debug("Parsing image's signature failed\n");
> > msg = NULL;
> > - goto err;
> > + continue;
> > }
> >
> > /* try black-list first */
> >
>
[PATCH v1 2/2] board: presidio-asic: Add CAxxxx Ethernet support
Add CA Ethernet support for the Cortina Access
Presidio Engineering Board
Signed-off-by: Alex Nemirovsky
---
arch/arm/dts/ca-presidio-engboard.dts| 7 +++
board/cortina/presidio-asic/presidio.c | 21 +
configs/cortina_presidio-asic-emmc_defconfig | 4 +++-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/ca-presidio-engboard.dts
b/arch/arm/dts/ca-presidio-engboard.dts
index c03dacc..fff879d 100644
--- a/arch/arm/dts/ca-presidio-engboard.dts
+++ b/arch/arm/dts/ca-presidio-engboard.dts
@@ -66,4 +66,11 @@
spi-max-frequency = <10800>;
};
};
+
+ eth: ethnet@0xf430 {
+ compatible = "eth_cortina";
+ reg = <0x0 0xf432 0x34>,
+ <0x0 0xf43290d8 0x04>,
+ <0x0 0xf4304000 0x04>;
+ };
};
diff --git a/board/cortina/presidio-asic/presidio.c
b/board/cortina/presidio-asic/presidio.c
index 3c132f1..a0dbfd6 100644
--- a/board/cortina/presidio-asic/presidio.c
+++ b/board/cortina/presidio-asic/presidio.c
@@ -105,6 +105,27 @@ int board_init(void)
return 0;
}
+#ifndef CONFIG_DM_ETH
+/*
+ * Board specific ethernet initialization routine.
+ */
+int ca77xx_eth_initialize(bd_t *bis);
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+ unsigned int reg_data;
+
+ ca77xx_eth_initialize(bis);
+
+ // Power down GMAC4 TX/RX clock for EMI issue
+ reg_data = readl(0xf4304684);
+ reg_data |= (3 << 11);
+ writel(reg_data, 0xf4304684);
+
+ return rc;
+}
+#endif
+
int dram_init(void)
{
unsigned int ddr_size;
diff --git a/configs/cortina_presidio-asic-emmc_defconfig
b/configs/cortina_presidio-asic-emmc_defconfig
index e10008a..360ebeb 100644
--- a/configs/cortina_presidio-asic-emmc_defconfig
+++ b/configs/cortina_presidio-asic-emmc_defconfig
@@ -21,12 +21,14 @@ CONFIG_CMD_EXT4=y
CONFIG_OF_CONTROL=y
CONFIG_OF_LIVE=y
CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard"
-# CONFIG_NET is not set
CONFIG_DM=y
CONFIG_CORTINA_GPIO=y
CONFIG_DM_MMC=y
CONFIG_MMC_DW=y
CONFIG_MMC_DW_CORTINA=y
+CONFIG_PHYLIB=y
+CONFIG_DM_ETH=y
+CONFIG_CORTINA_NI_ENET=y
CONFIG_DM_SERIAL=y
CONFIG_CORTINA_UART=y
CONFIG_WDT=y
--
2.7.4
[PATCH v1 1/2] net: cortina_ni: Addd eth support for Cortina Access CAxxxx SoCs
From: Aaron Tseng
Add Cortina Access Ethernet device driver for CA SoCs.
This driver supports both legacy and DM_ETH network models.
Signed-off-by: Aaron Tseng
Signed-off-by: Alex Nemirovsky
CC: Joe Hershberger
CC: Abbie Chang
CC: Tom Rini
---
MAINTAINERS |4 +
drivers/net/Kconfig |7 +
drivers/net/Makefile |1 +
drivers/net/cortina_ni.c | 1955 ++
drivers/net/cortina_ni.h | 592 ++
5 files changed, 2559 insertions(+)
create mode 100644 drivers/net/cortina_ni.c
create mode 100644 drivers/net/cortina_ni.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8add9d4..1b166d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -181,6 +181,8 @@ F: drivers/gpio/cortina_gpio.c
F: drivers/watchdog/cortina_wdt.c
F: drivers/serial/serial_cortina.c
F: drivers/mmc/ca_dw_mmc.c
+F: drivers/net/cortina_ni.c
+F: drivers/net/cortina_ni.h
ARM/CZ.NIC TURRIS MOX SUPPORT
M: Marek Behun
@@ -732,6 +734,8 @@ F: drivers/gpio/cortina_gpio.c
F: drivers/watchdog/cortina_wdt.c
F: drivers/serial/serial_cortina.c
F: drivers/mmc/ca_dw_mmc.c
+F: drivers/net/cortina_ni.c
+F: drivers/net/cortina_ni.h
MIPS MSCC
M: Gregory CLEMENT
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f7855c9..45e0480 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -149,6 +149,13 @@ config BCMGENET
help
This driver supports the BCMGENET Ethernet MAC.
+config CORTINA_NI_ENET
+ bool "Cortina-Access Ethernet driver"
+ depends on DM_ETH && CORTINA_PLATFORM
+ help
+ The driver supports the Cortina-Access Ethernet MAC for
+ all supported CA SoCs
+
config DWC_ETH_QOS
bool "Synopsys DWC Ethernet QOS device support"
depends on DM_ETH
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 383ed1c..1d6ec4f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
obj-$(CONFIG_BCM_SF2_ETH_GMAC) += bcm-sf2-eth-gmac.o
obj-$(CONFIG_CALXEDA_XGMAC) += calxedaxgmac.o
+obj-$(CONFIG_CORTINA_NI_ENET) += cortina_ni.o
obj-$(CONFIG_CS8900) += cs8900.o
obj-$(CONFIG_TULIP) += dc2114x.o
obj-$(CONFIG_ETH_DESIGNWARE) += designware.o
diff --git a/drivers/net/cortina_ni.c b/drivers/net/cortina_ni.c
new file mode 100644
index 000..d1dd32c
--- /dev/null
+++ b/drivers/net/cortina_ni.c
@@ -0,0 +1,1955 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2020 Cortina Access Inc.
+ * Author: Aaron Tseng
+ *
+ * Ethernet MAC Driver for all supported CA SoCs
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cortina_ni.h"
+
+static u32 reg_value;
+
+/* port 0-3 are individual port connect to PHY directly */
+/* port 4-7 are LAN ports connected to QSGMII PHY */
+int active_port = NI_PORT_5; /* Physical port 5 */
+u32 ge_port_phy_addr; /* PHY address connected to active port */
+int auto_scan_active_port;
+
+#define HEADER_A_SIZE 8
+#define CORTINA_NI_DBG 1
+/*define CORTINA_NI_DBG if individual rx,tx,init needs to be called */
+
+#ifdef CONFIG_DM_ETH
+#if CORTINA_NI_DBG
+static struct udevice *dbg_dev;
+#endif
+static struct udevice *curr_dev;
+#else
+#if CORTINA_NI_DBG
+static struct eth_device *dbg_dev;
+#endif
+static struct eth_device *curr_dev;
+#endif
+
+#if defined(CONFIG_TARGET_SATURN_ASIC)
+#define CA_REG_READ(off)readl((u64)KSEG1_ATU_XLAT(off))
+#define CA_REG_WRITE(data, off) writel(data, (u64)KSEG1_ATU_XLAT(off))
+#else
+#define CA_REG_READ(off)readl((u64)off)
+#define CA_REG_WRITE(data, off) writel(data, (u64)off)
+#endif
+
+#ifdef CONFIG_DM_ETH
+int cortina_ni_recv(struct udevice *netdev);
+static int ca_ni_ofdata_to_platdata(struct udevice *dev);
+#else
+int cortina_ni_recv(struct eth_device *netdev);
+#if defined(CONFIG_TARGET_PRESIDIO_ASIC)
+#define GLB_BASE_ADDR 0xf432
+#define PER_MDIO_BASE_ADDR 0xf43290d8
+#define NI_HV_BASE_ADDR0xf4304000
+#elif defined(CONFIG_TARGET_SATURN_ASIC)
+#define GLB_BASE_ADDR 0x4410
+#define PER_MDIO_BASE_ADDR 0x522240d8
+#define NI_HV_BASE_ADDR0xd0004000
+#elif defined(CONFIG_TARGET_VENUS)
+#define GLB_BASE_ADDR 0xf4320028
+#define PER_MDIO_BASE_ADDR 0xf4329118
+#define NI_HV_BASE_ADDR0xf4304000
+#endif
+#endif
+
+static u32 *RDWRPTR_ADVANCE_ONE(u32 *x, unsigned long base, unsigned long max)
+{
+ if (x + 1 >= (u32 *)max)
+ return (u32 *)base;
+ else
+ return (x + 1);
+}
+
+static void ni_setup_mac_addr(void)
+{
+ unsigned char mac[6];
+
+ union NI_HV_GLB_MAC_ADDR_CFG0_t mac_addr_cfg0;
+
RE: [PATCH u-boot] eth/r8152: update the firmware
Marek Vasut [mailto:ma...@denx.de] > Sent: Tuesday, June 02, 2020 12:46 AM > > Update the firmware to improve compatibility for none-intel USB > > host controller. > > Can you be more specific about the problem you are fixing here ? > What is the problem ? There is low probability that the device may be lost when rebooting. Should I submit v2 to reword the commit message? Best Regards, Hayes
Re: [PULL] Pull request: u-boot-stm32 for v2020.07: u-boot-stm32-20200528
On Thu, May 28, 2020 at 08:08:32AM +, Patrick DELAUNAY wrote: > Hi Tom, > > Please pull the STM32 related patches for v2020.07: u-boot-stm32-20200528 > > With the following changes: > - stm32mp15: fix DT on DHCOR SOM and avenger96 board > - stm32mp15: re-enable KS8851 on DHCOM > > > CI status: > https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/3462 > > Thanks, > Patrick > > The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-05-27 > 10:56:25 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20200528 > > for you to fetch changes up to 08f372ac2ade7a87581c00aa8fc59a2878525cb2: > > ARM: dts: stm32: Disable SDR104 mode on AV96 (2020-05-28 08:52:04 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
