Re: [U-Boot] [v2 1/5] Revert "ata: fsl_ahci: Add sata DM support for Freescale powerpc socs"
Hi Peng,
On 02.12.19 04:40, Peng Ma wrote:
This reverts commit 1ee494291880fd51ef0c5f7342e072bdb069d7ff.
Commit 1ee494291880 ("ata: fsl_ahci: Add sata DM support for Freescale
powerpc socs") introduced SCSI layer to call AHCI private API in order
to support sata operations, In DM mode, This is not necessary for
non-AHCI sata. So revert it and have already updated the driver itself
to operate sata directly.
Signed-off-by: Peng Ma
---
Changed for v2:
- Add detailed explanation.
Thanks for adding a more detailed decription here. But at first glance
I still failed to unterstand this. What's missing is (at least for me),
that you explain that you added a new DM enabled SATA driver to support
this controller [1] which makes this AHCI driver superfluous.
Is this explanation correct?
If yes, then feel free to add my:
Reviewed-by: Stefan Roese
to the complete patchset.
Thanks,
Stefan
[1] drivers/ata/fsl_sata.c
drivers/ata/Kconfig| 10 -
drivers/ata/Makefile |1 -
drivers/ata/fsl_ahci.c | 1030
drivers/ata/fsl_sata.h |1 -
4 files changed, 1042 deletions(-)
delete mode 100644 drivers/ata/fsl_ahci.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index fe589d3aa8..d8c9756c2a 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -59,16 +59,6 @@ config DWC_AHCI
Enable this driver to support Sata devices through
Synopsys DWC AHCI module.
-config FSL_AHCI
- bool "Enable Freescale AHCI driver support"
- select SCSI_AHCI
- depends on AHCI
- depends on DM_SCSI
- help
- Enable this driver to support Sata devices found in
- some Freescale PowerPC SoCs.
-
-
config DWC_AHSATA
bool "Enable DWC AHSATA driver support"
select LIBATA
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e03384f81..a69edb10f7 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -4,7 +4,6 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
-obj-$(CONFIG_FSL_AHCI) += fsl_ahci.o
obj-$(CONFIG_AHCI) += ahci-uclass.o
obj-$(CONFIG_AHCI_PCI) += ahci-pci.o
obj-$(CONFIG_SCSI_AHCI) += ahci.o
diff --git a/drivers/ata/fsl_ahci.c b/drivers/ata/fsl_ahci.c
deleted file mode 100644
index d04cff3ee7..00
--- a/drivers/ata/fsl_ahci.c
+++ /dev/null
@@ -1,1030 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * NXP PPC SATA platform driver
- *
- * (C) Copyright 2019 NXP, Inc.
- *
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "fsl_sata.h"
-
-struct fsl_ahci_priv {
- u32 base;
- u32 flag;
- u32 number;
- fsl_sata_t *fsl_sata;
-};
-
-static int fsl_ahci_bind(struct udevice *dev)
-{
- return device_bind_driver(dev, "fsl_ahci_scsi", "fsl_ahci_scsi", NULL);
-}
-
-static int fsl_ahci_ofdata_to_platdata(struct udevice *dev)
-{
- struct fsl_ahci_priv *priv = dev_get_priv(dev);
-
- priv->number = dev_read_u32_default(dev, "sata-number", -1);
- priv->flag = dev_read_u32_default(dev, "sata-fpdma", -1);
-
- priv->base = dev_read_addr(dev);
- if (priv->base == FDT_ADDR_T_NONE)
- return -EINVAL;
-
- return 0;
-}
-
-static int ata_wait_register(unsigned __iomem *addr, u32 mask,
-u32 val, u32 timeout_msec)
-{
- int i;
-
- for (i = 0; ((in_le32(addr) & mask) != val) && i < timeout_msec; i++)
- mdelay(1);
-
- return (i < timeout_msec) ? 0 : -1;
-}
-
-static void fsl_sata_dump_sfis(struct sata_fis_d2h *s)
-{
- printf("Status FIS dump:\n\r");
- printf("fis_type: %02x\n\r", s->fis_type);
- printf("pm_port_i: %02x\n\r", s->pm_port_i);
- printf("status:%02x\n\r", s->status);
- printf("error: %02x\n\r", s->error);
- printf("lba_low: %02x\n\r", s->lba_low);
- printf("lba_mid: %02x\n\r", s->lba_mid);
- printf("lba_high: %02x\n\r", s->lba_high);
- printf("device:%02x\n\r", s->device);
- printf("lba_low_exp: %02x\n\r", s->lba_low_exp);
- printf("lba_mid_exp: %02x\n\r", s->lba_mid_exp);
- printf("lba_high_exp: %02x\n\r", s->lba_high_exp);
- printf("res1: %02x\n\r", s->res1);
- printf("sector_count: %02x\n\r", s->sector_count);
- printf("sector_count_exp: %02x\n\r", s->sector_count_exp);
-}
-
-static void fsl_sata_dump_regs(fsl_sata_reg_t __iomem *reg)
-{
- printf("\n\rSATA: %08x\n\r", (u32)reg);
- printf("CQR:%08x\n\r", in_le32(®->cqr));
- printf("CAR:%08x\n\r", in_le32(®->car));
- printf("CCR:%08x\n\r", in_le32(®->ccr));
- printf("CER:%08x
Re: [U-Boot] [PATCH v3] gpio: at91_gpio: Add bank names
On 26.11.2019 13:52, James Byrne wrote: > Make the at91_gpio driver set sensible GPIO bank names in the platform > data. This makes the 'gpio status' command a lot more useful. > > Signed-off-by: James Byrne > > --- > Applied to u-boot-atmel/master Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: Remove unnecessary inclusion of micrel.h from boards
On 15.11.2019 19:11, James Byrne wrote: > Several boards still unnecessarily included micrel.h but no longer > require it since the switch to Device Tree configuration. > > Signed-off-by: James Byrne > Applied to u-boot-atmel/master Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Fix BMP decode when BMP size is bigger than framebuffer
Hi Anatolij Just a reminder for this series which fixes stm32f746-disco boot when trying to display a splashcreen. Thanks Patrice On 11/20/19 2:11 PM, Patrice Chotard wrote: > This series is fixing 2 issues found when trying to decode BMP > bigger than the framebuffer: > - Convert panel_picture_delta from unsigned long to long to insure >to store correctly the difference between panel_size and picture_size >in case the panel_size is smaller than picture_size. > - Don't rely on BMP's width and height but in width and height >value computed by video_bmp_display(). > > > Changes in v2: > - Convert panel_picture_delta from unsigned long to long > > Patrice Chotard (2): > video: bmp: Fix video_splash_align_axis() > video: bmp: Fix video_display_rle8_bitmap() > > drivers/video/video_bmp.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [v2 1/5] Revert "ata: fsl_ahci: Add sata DM support for Freescale powerpc socs"
>-Original Message-
>From: Stefan Roese
>Sent: 2019年12月2日 15:59
>To: Peng Ma ; Priyanka Jain ;
>w...@denx.de; Ruchika Gupta ; Shengzhou Liu
>
>Cc: Yinbo Zhu ; Z.q. Hou ;
>s...@chromium.org; ja...@openedev.com; andre.przyw...@arm.com;
>sm...@web.de; Andy Tang ; u-boot@lists.denx.de
>Subject: [EXT] Re: [v2 1/5] Revert "ata: fsl_ahci: Add sata DM support for
>Freescale powerpc socs"
>
>Caution: EXT Email
>
>Hi Peng,
>
>On 02.12.19 04:40, Peng Ma wrote:
>> This reverts commit 1ee494291880fd51ef0c5f7342e072bdb069d7ff.
>>
>> Commit 1ee494291880 ("ata: fsl_ahci: Add sata DM support for Freescale
>> powerpc socs") introduced SCSI layer to call AHCI private API in order
>> to support sata operations, In DM mode, This is not necessary for
>> non-AHCI sata. So revert it and have already updated the driver itself
>> to operate sata directly.
>>
>> Signed-off-by: Peng Ma
>> ---
>> Changed for v2:
>> - Add detailed explanation.
>
>Thanks for adding a more detailed decription here. But at first glance I still
>failed to unterstand this. What's missing is (at least for me), that you
>explain
>that you added a new DM enabled SATA driver to support this controller [1]
>which makes this AHCI driver superfluous.
>
>Is this explanation correct?
>
>If yes, then feel free to add my:
>
>Reviewed-by: Stefan Roese
>
>to the complete patchset.
>
Hi, Stefan,
Thanks for your quick comments, You understand exactly right.
Best Regards,
Peng
>Thanks,
>Stefan
>
>[1] drivers/ata/fsl_sata.c
>
>> drivers/ata/Kconfig| 10 -
>> drivers/ata/Makefile |1 -
>> drivers/ata/fsl_ahci.c | 1030
>> drivers/ata/fsl_sata.h |1 -
>> 4 files changed, 1042 deletions(-)
>> delete mode 100644 drivers/ata/fsl_ahci.c
>>
>> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index
>> fe589d3aa8..d8c9756c2a 100644
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -59,16 +59,6 @@ config DWC_AHCI
>> Enable this driver to support Sata devices through
>> Synopsys DWC AHCI module.
>>
>> -config FSL_AHCI
>> - bool "Enable Freescale AHCI driver support"
>> - select SCSI_AHCI
>> - depends on AHCI
>> - depends on DM_SCSI
>> - help
>> - Enable this driver to support Sata devices found in
>> - some Freescale PowerPC SoCs.
>> -
>> -
>> config DWC_AHSATA
>> bool "Enable DWC AHSATA driver support"
>> select LIBATA
>> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index
>> 6e03384f81..a69edb10f7 100644
>> --- a/drivers/ata/Makefile
>> +++ b/drivers/ata/Makefile
>> @@ -4,7 +4,6 @@
>> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>>
>> obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
>> -obj-$(CONFIG_FSL_AHCI) += fsl_ahci.o
>> obj-$(CONFIG_AHCI) += ahci-uclass.o
>> obj-$(CONFIG_AHCI_PCI) += ahci-pci.o
>> obj-$(CONFIG_SCSI_AHCI) += ahci.o
>> diff --git a/drivers/ata/fsl_ahci.c b/drivers/ata/fsl_ahci.c deleted
>> file mode 100644 index d04cff3ee7..00
>> --- a/drivers/ata/fsl_ahci.c
>> +++ /dev/null
>> @@ -1,1030 +0,0 @@
>> -// SPDX-License-Identifier: GPL-2.0+
>> -/*
>> - * NXP PPC SATA platform driver
>> - *
>> - * (C) Copyright 2019 NXP, Inc.
>> - *
>> - */
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -#include "fsl_sata.h"
>> -
>> -struct fsl_ahci_priv {
>> - u32 base;
>> - u32 flag;
>> - u32 number;
>> - fsl_sata_t *fsl_sata;
>> -};
>> -
>> -static int fsl_ahci_bind(struct udevice *dev) -{
>> - return device_bind_driver(dev, "fsl_ahci_scsi", "fsl_ahci_scsi", NULL);
>> -}
>> -
>> -static int fsl_ahci_ofdata_to_platdata(struct udevice *dev) -{
>> - struct fsl_ahci_priv *priv = dev_get_priv(dev);
>> -
>> - priv->number = dev_read_u32_default(dev, "sata-number", -1);
>> - priv->flag = dev_read_u32_default(dev, "sata-fpdma", -1);
>> -
>> - priv->base = dev_read_addr(dev);
>> - if (priv->base == FDT_ADDR_T_NONE)
>> - return -EINVAL;
>> -
>> - return 0;
>> -}
>> -
>> -static int ata_wait_register(unsigned __iomem *addr, u32 mask,
>> - u32 val, u32 timeout_msec)
>> -{
>> - int i;
>> -
>> - for (i = 0; ((in_le32(addr) & mask) != val) && i < timeout_msec; i++)
>> - mdelay(1);
>> -
>> - return (i < timeout_msec) ? 0 : -1;
>> -}
>> -
>> -static void fsl_sata_dump_sfis(struct sata_fis_d2h *s) -{
>> - printf("Status FIS dump:\n\r");
>> - printf("fis_type: %02x\n\r", s->fis_type);
>> - printf("pm_port_i: %02x\n\r", s->pm_port_i);
>> - printf("status: %02x\n\r", s->status);
>> - printf("error: %02x\n\r", s->error);
>> - printf("lba_low:%02x\n\r", s->lba_low);
>> - printf("lba_mid:%02x\n\r", s->lba_mid);
>> - printf("lba_high: %02x\n\r", s->lba_high)
[U-Boot] [PATCH RESEND v2 00/10] dma: ti: k3-udma: Add support for J721e
This series adds DMA support for J721e using exist K3 UDMA driver. One main change is thati, on J721e, DMA resources such as DMA channels are shared between different entities running on different cores of the SoC. Therefore, U-Boot running on A72 core should request range of resources allocated to it from centralized resource management core (DMSC) and use only the allocated resource. First two patches adds support for dynamically querying and using allocated resources. Remaining patches fix issues when using UDMA driver on a 32 bit core like R5. Last patch adds a new compatible for J721e Vignesh Raghavendra (10): lib: Import few bitmap functions from Linux dma: ti: k3-udma: Query DMA channels allocated from Resource Manager soc: ti: k3-navss-ringacc: Flush/invalidate caches on ring push/pop soc: ti: k3-navss-ringacc: Get SYSFW reference from DT phandle dma: ti: k3-udma: Remove coherency check for cache ops dma: ti: k3-udma: Fix debug prints during enabling MEM_TO_DEV transfers dma: ti: k3-udma: Switch to exposed ring mode dma: ti: k3-udma: Fix ring push operation for 32 bit cores dma: ti: k3-udma: Fix build warnings when building for 32 bit platforms dma: ti: k3-udma: Add new compatible to J721e drivers/dma/ti/k3-udma-hwdef.h| 19 ++ drivers/dma/ti/k3-udma.c | 346 -- drivers/soc/ti/k3-navss-ringacc.c | 13 +- include/linux/bitmap.h| 133 include/linux/bitops.h| 12 ++ 5 files changed, 403 insertions(+), 120 deletions(-) -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 08/10] dma: ti: k3-udma: Fix ring push operation for 32 bit cores
UDMA always expects 64 bit address pointer of the transfer descriptor in
the Ring. But on 32 bit cores like R5, pointer is always 32 bit in size.
Therefore copy over 32 bit pointer value to 64 bit variable before
pushing it over to the ring, so that upper 32 bits are 0s.
Signed-off-by: Vignesh Raghavendra
---
drivers/dma/ti/k3-udma.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 783195572763..33b1d7880bed 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1359,6 +1359,14 @@ static int udma_probe(struct udevice *dev)
return ret;
}
+static int udma_push_to_ring(struct k3_nav_ring *ring, void *elem)
+{
+ u64 addr = 0;
+
+ memcpy(&addr, &elem, sizeof(elem));
+ return k3_nav_ringacc_ring_push(ring, &addr);
+}
+
static int *udma_prep_dma_memcpy(struct udma_chan *uc, dma_addr_t dest,
dma_addr_t src, size_t len)
{
@@ -1450,7 +1458,7 @@ static int *udma_prep_dma_memcpy(struct udma_chan *uc,
dma_addr_t dest,
ALIGN((u64)tr_desc + desc_size,
ARCH_DMA_MINALIGN));
- k3_nav_ringacc_ring_push(uc->tchan->t_ring, &tr_desc);
+ udma_push_to_ring(uc->tchan->t_ring, tr_desc);
return 0;
}
@@ -1620,7 +1628,7 @@ static int udma_send(struct dma *dma, void *src, size_t
len, void *metadata)
ALIGN((u64)desc_tx + uc->hdesc_size,
ARCH_DMA_MINALIGN));
- ret = k3_nav_ringacc_ring_push(uc->tchan->t_ring, &uc->desc_tx);
+ ret = udma_push_to_ring(uc->tchan->t_ring, uc->desc_tx);
if (ret) {
dev_err(dma->dev, "TX dma push fail ch_id %lu %d\n",
dma->id, ret);
@@ -1779,7 +1787,7 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst,
size_t size)
ALIGN((u64)desc_rx + uc->hdesc_size,
ARCH_DMA_MINALIGN));
- k3_nav_ringacc_ring_push(uc->rchan->fd_ring, &desc_rx);
+ udma_push_to_ring(uc->rchan->fd_ring, desc_rx);
uc->num_rx_bufs++;
uc->desc_rx_cur++;
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 09/10] dma: ti: k3-udma: Fix build warnings when building for 32 bit platforms
Cast pointers properly so as to avoid warnings when driver is built for 32 bit platforms Signed-off-by: Vignesh Raghavendra --- drivers/dma/ti/k3-udma.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c index 33b1d7880bed..03c48c9d1ee2 100644 --- a/drivers/dma/ti/k3-udma.c +++ b/drivers/dma/ti/k3-udma.c @@ -1454,8 +1454,8 @@ static int *udma_prep_dma_memcpy(struct udma_chan *uc, dma_addr_t dest, cppi5_tr_csf_set(&tr_req[num_tr - 1].flags, CPPI5_TR_CSF_EOP); - flush_dcache_range((u64)tr_desc, - ALIGN((u64)tr_desc + desc_size, + flush_dcache_range((unsigned long)tr_desc, + ALIGN((unsigned long)tr_desc + desc_size, ARCH_DMA_MINALIGN)); udma_push_to_ring(uc->tchan->t_ring, tr_desc); @@ -1621,11 +1621,11 @@ static int udma_send(struct dma *dma, void *src, size_t len, void *metadata) cppi5_hdesc_set_pkttype(desc_tx, packet_data.pkt_type); cppi5_desc_set_tags_ids(&desc_tx->hdr, 0, packet_data.dest_tag); - flush_dcache_range((u64)dma_src, - ALIGN((u64)dma_src + len, + flush_dcache_range((unsigned long)dma_src, + ALIGN((unsigned long)dma_src + len, ARCH_DMA_MINALIGN)); - flush_dcache_range((u64)desc_tx, - ALIGN((u64)desc_tx + uc->hdesc_size, + flush_dcache_range((unsigned long)desc_tx, + ALIGN((unsigned long)desc_tx + uc->hdesc_size, ARCH_DMA_MINALIGN)); ret = udma_push_to_ring(uc->tchan->t_ring, uc->desc_tx); @@ -1783,8 +1783,8 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst, size_t size) cppi5_hdesc_set_pktlen(desc_rx, size); cppi5_hdesc_attach_buf(desc_rx, dma_dst, size, dma_dst, size); - flush_dcache_range((u64)desc_rx, - ALIGN((u64)desc_rx + uc->hdesc_size, + flush_dcache_range((unsigned long)desc_rx, + ALIGN((unsigned long)desc_rx + uc->hdesc_size, ARCH_DMA_MINALIGN)); udma_push_to_ring(uc->rchan->fd_ring, desc_rx); -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 07/10] dma: ti: k3-udma: Switch to exposed ring mode
Exposed ring mode works well with 32 bit and 64 bit cores without need for Proxies for 32 bit cores. Therefore switch to exposed ring mode. Signed-off-by: Vignesh Raghavendra --- drivers/dma/ti/k3-udma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c index ed5c64522a8e..783195572763 100644 --- a/drivers/dma/ti/k3-udma.c +++ b/drivers/dma/ti/k3-udma.c @@ -759,7 +759,7 @@ static int udma_alloc_tx_resources(struct udma_chan *uc) memset(&ring_cfg, 0, sizeof(ring_cfg)); ring_cfg.size = 16; ring_cfg.elm_size = K3_NAV_RINGACC_RING_ELSIZE_8; - ring_cfg.mode = K3_NAV_RINGACC_RING_MODE_MESSAGE; + ring_cfg.mode = K3_NAV_RINGACC_RING_MODE_RING; ret = k3_nav_ringacc_ring_cfg(uc->tchan->t_ring, &ring_cfg); ret |= k3_nav_ringacc_ring_cfg(uc->tchan->tc_ring, &ring_cfg); @@ -836,7 +836,7 @@ static int udma_alloc_rx_resources(struct udma_chan *uc) memset(&ring_cfg, 0, sizeof(ring_cfg)); ring_cfg.size = 16; ring_cfg.elm_size = K3_NAV_RINGACC_RING_ELSIZE_8; - ring_cfg.mode = K3_NAV_RINGACC_RING_MODE_MESSAGE; + ring_cfg.mode = K3_NAV_RINGACC_RING_MODE_RING; ret = k3_nav_ringacc_ring_cfg(uc->rchan->fd_ring, &ring_cfg); ret |= k3_nav_ringacc_ring_cfg(uc->rchan->r_ring, &ring_cfg); -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 01/10] lib: Import few bitmap functions from Linux
Import few basic bitmap functions (bitmap_{weight,fill,set,clear,or}())
and their dependencies from Linux. These are required for upcoming DMA
resource allocation support for TI's K3 SoCs.
Signed-off-by: Vignesh Raghavendra
---
include/linux/bitmap.h | 133 +
include/linux/bitops.h | 12
2 files changed, 145 insertions(+)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index fbbb67c8b24e..dae4225be549 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -5,10 +5,88 @@
#include
#include
#include
+#include
+#ifdef __LITTLE_ENDIAN
+#define BITMAP_MEM_ALIGNMENT 8
+#else
+#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long))
+#endif
+#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1)
+
+#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1)))
+#define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1)))
#define small_const_nbits(nbits) \
(__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)
+static inline void
+__bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
+ const unsigned long *bitmap2, unsigned int bits)
+{
+ unsigned int k;
+ unsigned int nr = BITS_TO_LONGS(bits);
+
+ for (k = 0; k < nr; k++)
+ dst[k] = bitmap1[k] | bitmap2[k];
+}
+
+static inline int
+__bitmap_weight(const unsigned long *bitmap, unsigned int bits)
+{
+ unsigned int k, lim = bits / BITS_PER_LONG;
+ int w = 0;
+
+ for (k = 0; k < lim; k++)
+ w += hweight_long(bitmap[k]);
+
+ if (bits % BITS_PER_LONG)
+ w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));
+
+ return w;
+}
+
+static inline void
+__bitmap_set(unsigned long *map, unsigned int start, int len)
+{
+ unsigned long *p = map + BIT_WORD(start);
+ const unsigned int size = start + len;
+ int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
+ unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
+
+ while (len - bits_to_set >= 0) {
+ *p |= mask_to_set;
+ len -= bits_to_set;
+ bits_to_set = BITS_PER_LONG;
+ mask_to_set = ~0UL;
+ p++;
+ }
+ if (len) {
+ mask_to_set &= BITMAP_LAST_WORD_MASK(size);
+ *p |= mask_to_set;
+ }
+}
+
+static inline void
+__bitmap_clear(unsigned long *map, unsigned int start, int len)
+{
+ unsigned long *p = map + BIT_WORD(start);
+ const unsigned int size = start + len;
+ int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
+ unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK(start);
+
+ while (len - bits_to_clear >= 0) {
+ *p &= ~mask_to_clear;
+ len -= bits_to_clear;
+ bits_to_clear = BITS_PER_LONG;
+ mask_to_clear = ~0UL;
+ p++;
+ }
+ if (len) {
+ mask_to_clear &= BITMAP_LAST_WORD_MASK(size);
+ *p &= ~mask_to_clear;
+ }
+}
+
static inline void bitmap_zero(unsigned long *dst, int nbits)
{
if (small_const_nbits(nbits)) {
@@ -81,4 +159,59 @@ static inline unsigned long find_first_bit(const unsigned
long *addr, unsigned l
(bit) < (size);\
(bit) = find_next_bit((addr), (size), (bit) + 1))
+static inline void bitmap_fill(unsigned long *dst, unsigned int nbits)
+{
+ if (small_const_nbits(nbits)) {
+ *dst = ~0UL;
+ } else {
+ unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
+
+ memset(dst, 0xff, len);
+ }
+}
+
+static inline void bitmap_or(unsigned long *dst, const unsigned long *src1,
+const unsigned long *src2, unsigned int nbits)
+{
+ if (small_const_nbits(nbits))
+ *dst = *src1 | *src2;
+ else
+ __bitmap_or(dst, src1, src2, nbits);
+}
+
+static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)
+{
+ if (small_const_nbits(nbits))
+ return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
+ return __bitmap_weight(src, nbits);
+}
+
+static inline void bitmap_set(unsigned long *map, unsigned int start,
+ unsigned int nbits)
+{
+ if (__builtin_constant_p(nbits) && nbits == 1)
+ __set_bit(start, map);
+ else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+__builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
+ memset((char *)map + start / 8, 0xff, nbits / 8);
+ else
+ __bitmap_set(map, start, nbits);
+}
+
+static inline void bitmap_clear(unsigned long *map, unsigned int start,
+ unsigned int
[U-Boot] [PATCH RESEND v2 05/10] dma: ti: k3-udma: Remove coherency check for cache ops
Remove redundant coherency checks before calling cache ops in UDMA
driver. This is now handled in arch specific cache operation
implementation based on Kconfig option
Signed-off-by: Vignesh Raghavendra
---
drivers/dma/ti/k3-udma.c | 49 +---
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 2f82ab0955a4..ee4bc531cb50 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -93,7 +93,6 @@ struct udma_dev {
u32 psil_base;
u32 ch_count;
- bool is_coherent;
};
struct udma_chan {
@@ -274,11 +273,6 @@ static inline bool udma_is_chan_running(struct udma_chan
*uc)
return false;
}
-static int udma_is_coherent(struct udma_chan *uc)
-{
- return uc->ud->is_coherent;
-}
-
static int udma_pop_from_ring(struct udma_chan *uc, dma_addr_t *addr)
{
struct k3_nav_ring *ring = NULL;
@@ -1305,7 +1299,6 @@ static int udma_probe(struct udevice *dev)
return ret;
}
- ud->is_coherent = dev_read_bool(dev, "dma-coherent");
tisci_rm->tisci_udmap_ops = &tisci_rm->tisci->ops.rm_udmap_ops;
tisci_rm->tisci_psil_ops = &tisci_rm->tisci->ops.rm_psil_ops;
@@ -1453,11 +1446,9 @@ static int *udma_prep_dma_memcpy(struct udma_chan *uc,
dma_addr_t dest,
cppi5_tr_csf_set(&tr_req[num_tr - 1].flags, CPPI5_TR_CSF_EOP);
- if (!udma_is_coherent(uc)) {
- flush_dcache_range((u64)tr_desc,
- ALIGN((u64)tr_desc + desc_size,
-ARCH_DMA_MINALIGN));
- }
+ flush_dcache_range((u64)tr_desc,
+ ALIGN((u64)tr_desc + desc_size,
+ARCH_DMA_MINALIGN));
k3_nav_ringacc_ring_push(uc->tchan->t_ring, &tr_desc);
@@ -1622,14 +1613,12 @@ static int udma_send(struct dma *dma, void *src, size_t
len, void *metadata)
cppi5_hdesc_set_pkttype(desc_tx, packet_data.pkt_type);
cppi5_desc_set_tags_ids(&desc_tx->hdr, 0, packet_data.dest_tag);
- if (!udma_is_coherent(uc)) {
- flush_dcache_range((u64)dma_src,
- ALIGN((u64)dma_src + len,
-ARCH_DMA_MINALIGN));
- flush_dcache_range((u64)desc_tx,
- ALIGN((u64)desc_tx + uc->hdesc_size,
-ARCH_DMA_MINALIGN));
- }
+ flush_dcache_range((u64)dma_src,
+ ALIGN((u64)dma_src + len,
+ARCH_DMA_MINALIGN));
+ flush_dcache_range((u64)desc_tx,
+ ALIGN((u64)desc_tx + uc->hdesc_size,
+ARCH_DMA_MINALIGN));
ret = k3_nav_ringacc_ring_push(uc->tchan->t_ring, &uc->desc_tx);
if (ret) {
@@ -1673,19 +1662,15 @@ static int udma_receive(struct dma *dma, void **dst,
void *metadata)
}
/* invalidate cache data */
- if (!udma_is_coherent(uc)) {
- invalidate_dcache_range((ulong)desc_rx,
- (ulong)(desc_rx + uc->hdesc_size));
- }
+ invalidate_dcache_range((ulong)desc_rx,
+ (ulong)(desc_rx + uc->hdesc_size));
cppi5_hdesc_get_obuf(desc_rx, &buf_dma, &buf_dma_len);
pkt_len = cppi5_hdesc_get_pktlen(desc_rx);
/* invalidate cache data */
- if (!udma_is_coherent(uc)) {
- invalidate_dcache_range((ulong)buf_dma,
- (ulong)(buf_dma + buf_dma_len));
- }
+ invalidate_dcache_range((ulong)buf_dma,
+ (ulong)(buf_dma + buf_dma_len));
cppi5_desc_get_tags_ids(&desc_rx->hdr, &port_id, NULL);
@@ -1790,11 +1775,9 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst,
size_t size)
cppi5_hdesc_set_pktlen(desc_rx, size);
cppi5_hdesc_attach_buf(desc_rx, dma_dst, size, dma_dst, size);
- if (!udma_is_coherent(uc)) {
- flush_dcache_range((u64)desc_rx,
- ALIGN((u64)desc_rx + uc->hdesc_size,
-ARCH_DMA_MINALIGN));
- }
+ flush_dcache_range((u64)desc_rx,
+ ALIGN((u64)desc_rx + uc->hdesc_size,
+ARCH_DMA_MINALIGN));
k3_nav_ringacc_ring_push(uc->rchan->fd_ring, &desc_rx);
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 04/10] soc: ti: k3-navss-ringacc: Get SYSFW reference from DT phandle
Instead of looking getting reference to SYSFW device using name which
is not guaranteed to be constant, use phandle supplied in the DT node to
get reference to SYSFW
Signed-off-by: Vignesh Raghavendra
---
drivers/soc/ti/k3-navss-ringacc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/ti/k3-navss-ringacc.c
b/drivers/soc/ti/k3-navss-ringacc.c
index 08b476d21049..c71f6576bdf8 100644
--- a/drivers/soc/ti/k3-navss-ringacc.c
+++ b/drivers/soc/ti/k3-navss-ringacc.c
@@ -941,7 +941,8 @@ static int k3_nav_ringacc_probe_dt(struct k3_nav_ringacc
*ringacc)
ringacc->dma_ring_reset_quirk =
dev_read_bool(dev, "ti,dma-ring-reset-quirk");
- ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", &tisci_dev);
+ ret = uclass_get_device_by_phandle(UCLASS_FIRMWARE, dev,
+ "ti,sci", &tisci_dev);
if (ret) {
pr_debug("TISCI RA RM get failed (%d)\n", ret);
ringacc->tisci = NULL;
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 10/10] dma: ti: k3-udma: Add new compatible to J721e
Add new compatible to handle UDMA support for J721e SoC
Signed-off-by: Vignesh Raghavendra
---
drivers/dma/ti/k3-udma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 03c48c9d1ee2..def3c5c38c66 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1809,6 +1809,7 @@ static const struct dma_ops udma_ops = {
static const struct udevice_id udma_ids[] = {
{ .compatible = "ti,k3-navss-udmap" },
+ { .compatible = "ti,j721e-navss-main-udmap" },
{ }
};
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 03/10] soc: ti: k3-navss-ringacc: Flush/invalidate caches on ring push/pop
Flush caches when pushing an element to ring and invalidate caches when popping an element from ring in Exposed Ring mode. Otherwise DMA transfers don't work properly in R5 SPL (with caches enabled) where the core is not in coherency domain. Reviewed-by: Grygorii Strashko Signed-off-by: Vignesh Raghavendra --- drivers/soc/ti/k3-navss-ringacc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/soc/ti/k3-navss-ringacc.c b/drivers/soc/ti/k3-navss-ringacc.c index 64ebc0ba0030..08b476d21049 100644 --- a/drivers/soc/ti/k3-navss-ringacc.c +++ b/drivers/soc/ti/k3-navss-ringacc.c @@ -807,6 +807,11 @@ static int k3_nav_ringacc_ring_push_mem(struct k3_nav_ring *ring, void *elem) memcpy(elem_ptr, elem, (4 << ring->elm_size)); + flush_dcache_range((unsigned long)ring->ring_mem_virt, + ALIGN((unsigned long)ring->ring_mem_virt + +ring->size * (4 << ring->elm_size), +ARCH_DMA_MINALIGN)); + ring->windex = (ring->windex + 1) % ring->size; ring->free--; ringacc_writel(1, &ring->rt->db); @@ -823,6 +828,11 @@ static int k3_nav_ringacc_ring_pop_mem(struct k3_nav_ring *ring, void *elem) elem_ptr = k3_nav_ringacc_get_elm_addr(ring, ring->rindex); + invalidate_dcache_range((unsigned long)ring->ring_mem_virt, + ALIGN((unsigned long)ring->ring_mem_virt + + ring->size * (4 << ring->elm_size), + ARCH_DMA_MINALIGN)); + memcpy(elem, elem_ptr, (4 << ring->elm_size)); ring->rindex = (ring->rindex + 1) % ring->size; -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 06/10] dma: ti: k3-udma: Fix debug prints during enabling MEM_TO_DEV transfers
Fix up the debug prints that were dumping state of TCHAN RT registers to
use tchan for MEM_TO_DEV transfers.
Signed-off-by: Vignesh Raghavendra
---
drivers/dma/ti/k3-udma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index ee4bc531cb50..ed5c64522a8e 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -427,9 +427,9 @@ static int udma_start(struct udma_chan *uc)
pr_debug("%s(tx): RT_CTL:0x%08x PEER RT_ENABLE:0x%08x\n",
__func__,
-udma_rchanrt_read(uc->rchan,
+udma_tchanrt_read(uc->tchan,
UDMA_TCHAN_RT_CTL_REG),
-udma_rchanrt_read(uc->rchan,
+udma_tchanrt_read(uc->tchan,
UDMA_TCHAN_RT_PEER_RT_EN_REG));
break;
case DMA_MEM_TO_MEM:
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v2 02/10] dma: ti: k3-udma: Query DMA channels allocated from Resource Manager
On K3 SoCs, DMA channels are shared across multiple entities, therefore
U-Boot DMA driver needs to query resource range from centralised
resource management controller i.e SystemFirmware and use DMA channels
allocated for A72 host. Add support for the same.
Signed-off-by: Vignesh Raghavendra
---
v2:
Address comments on v1 from Grygorii
Squash patch 5 (of v1) into this patch
drivers/dma/ti/k3-udma-hwdef.h | 19 +++
drivers/dma/ti/k3-udma.c | 274 +++--
2 files changed, 214 insertions(+), 79 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-hwdef.h b/drivers/dma/ti/k3-udma-hwdef.h
index c88399a815ea..228a44cb73cf 100644
--- a/drivers/dma/ti/k3-udma-hwdef.h
+++ b/drivers/dma/ti/k3-udma-hwdef.h
@@ -181,4 +181,23 @@
#define PDMA_STATIC_TR_Z(x)\
(((x) << PDMA_STATIC_TR_Z_SHIFT) & PDMA_STATIC_TR_Z_MASK)
+enum udma_rm_range {
+ RM_RANGE_TCHAN = 0,
+ RM_RANGE_RCHAN,
+ RM_RANGE_RFLOW,
+ RM_RANGE_LAST,
+};
+
+struct udma_tisci_rm {
+ const struct ti_sci_handle *tisci;
+ const struct ti_sci_rm_udmap_ops *tisci_udmap_ops;
+ u32 tisci_dev_id;
+
+ /* tisci information for PSI-L thread pairing/unpairing */
+ const struct ti_sci_rm_psil_ops *tisci_psil_ops;
+ u32 tisci_navss_dev_id;
+
+ struct ti_sci_resource *rm_ranges[RM_RANGE_LAST];
+};
+
#endif /* K3_NAVSS_UDMA_HWDEF_H_ */
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index a5fc7809bc41..2f82ab0955a4 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -11,12 +11,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -30,6 +32,8 @@
#define RINGACC_RING_USE_PROXY (1)
#endif
+#define K3_UDMA_MAX_RFLOWS 1024
+
struct udma_chan;
enum udma_mmr {
@@ -64,9 +68,10 @@ struct udma_rflow {
};
struct udma_dev {
- struct device *dev;
+ struct udevice *dev;
void __iomem *mmrs[MMR_LAST];
+ struct udma_tisci_rm tisci_rm;
struct k3_nav_ringacc *ringacc;
u32 features;
@@ -78,6 +83,7 @@ struct udma_dev {
unsigned long *tchan_map;
unsigned long *rchan_map;
unsigned long *rflow_map;
+ unsigned long *rflow_map_reserved;
struct udma_tchan *tchans;
struct udma_rchan *rchans;
@@ -87,11 +93,6 @@ struct udma_dev {
u32 psil_base;
u32 ch_count;
- const struct ti_sci_handle *tisci;
- const struct ti_sci_rm_udmap_ops *tisci_udmap_ops;
- const struct ti_sci_rm_psil_ops *tisci_psil_ops;
- u32 tisci_dev_id;
- u32 tisci_navss_dev_id;
bool is_coherent;
};
@@ -200,19 +201,25 @@ static inline void udma_rchanrt_write(struct udma_rchan
*rchan,
static inline int udma_navss_psil_pair(struct udma_dev *ud, u32 src_thread,
u32 dst_thread)
{
+ struct udma_tisci_rm *tisci_rm = &ud->tisci_rm;
+
dst_thread |= UDMA_PSIL_DST_THREAD_ID_OFFSET;
- return ud->tisci_psil_ops->pair(ud->tisci,
- ud->tisci_navss_dev_id,
- src_thread, dst_thread);
+
+ return tisci_rm->tisci_psil_ops->pair(tisci_rm->tisci,
+ tisci_rm->tisci_navss_dev_id,
+ src_thread, dst_thread);
}
static inline int udma_navss_psil_unpair(struct udma_dev *ud, u32 src_thread,
u32 dst_thread)
{
+ struct udma_tisci_rm *tisci_rm = &ud->tisci_rm;
+
dst_thread |= UDMA_PSIL_DST_THREAD_ID_OFFSET;
- return ud->tisci_psil_ops->unpair(ud->tisci,
- ud->tisci_navss_dev_id,
- src_thread, dst_thread);
+
+ return tisci_rm->tisci_psil_ops->unpair(tisci_rm->tisci,
+ tisci_rm->tisci_navss_dev_id,
+ src_thread, dst_thread);
}
static inline char *udma_get_dir_text(enum dma_direction dir)
@@ -535,6 +542,28 @@ static void udma_poll_completion(struct udma_chan *uc,
dma_addr_t *paddr)
}
}
+static struct udma_rflow *__udma_reserve_rflow(struct udma_dev *ud, int id)
+{
+ DECLARE_BITMAP(tmp, K3_UDMA_MAX_RFLOWS);
+
+ if (id >= 0) {
+ if (test_bit(id, ud->rflow_map)) {
+ dev_err(ud->dev, "rflow%d is in use\n", id);
+ return ERR_PTR(-ENOENT);
+ }
+ } else {
+ bitmap_or(tmp, ud->rflow_map, ud->rflow_map_reserved,
+ ud->rflow_cnt);
+
+ id = find_next_zero_bit(tmp, ud->rflow_cnt, ud->rchan_cnt);
+ if (id >= ud->rflow_cnt)
+ return ERR_PTR(-ENOENT);
+ }
+
+ __set_bit(id, ud->rflow_map);
+ retu
[U-Boot] [PATCH v2 2/6] dma: ti: k3-udma: Implement dma_get_cfg() interface
Implement dma_get_cfg() interface to pass flow id information for DMA
clients to use. This is needed because on K3 SoCs, CPSW (ethernet) and
UDMA (DMA provider) support "flows" within a given RX DMA channel. This
allows different network packets to be segregated while using same RX
DMA channel. In order for basic ethernet to work, CPSW slave must be
aware of the flow ID allocated for the RX channel by the DMA driver.
This interface allows CPSW to query flow ID from DMA provider and
configure it in CPSW HW.
Signed-off-by: Vignesh Raghavendra
Acked-by: Joe Hershberger
---
drivers/dma/ti/k3-udma.c | 28
include/linux/soc/ti/ti-udma.h | 19 +++
2 files changed, 47 insertions(+)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index def3c5c38c66..36bf349a8579 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -103,6 +103,8 @@ struct udma_chan {
struct udma_rchan *rchan;
struct udma_rflow *rflow;
+ struct ti_udma_drv_chan_cfg_data cfg_data;
+
u32 bcnt; /* number of bytes completed since the start of the channel */
bool pkt_mode; /* TR or packet */
@@ -1521,6 +1523,11 @@ static int udma_request(struct dma *dma)
uc->desc_rx_cur = 0;
uc->num_rx_bufs = 0;
+ if (uc->dir == DMA_DEV_TO_MEM) {
+ uc->cfg_data.flow_id_base = uc->rflow->id;
+ uc->cfg_data.flow_id_cnt = 1;
+ }
+
return 0;
}
@@ -1795,6 +1802,26 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst,
size_t size)
return 0;
}
+static int udma_get_cfg(struct dma *dma, u32 id, void **data)
+{
+ struct udma_dev *ud = dev_get_priv(dma->dev);
+ struct udma_chan *uc;
+
+ if (dma->id >= (ud->rchan_cnt + ud->tchan_cnt)) {
+ dev_err(dma->dev, "invalid dma ch_id %lu\n", dma->id);
+ return -EINVAL;
+ }
+
+ switch (id) {
+ case TI_UDMA_CHAN_PRIV_INFO:
+ uc = &ud->channels[dma->id];
+ *data = &uc->cfg_data;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static const struct dma_ops udma_ops = {
.transfer = udma_transfer,
.of_xlate = udma_of_xlate,
@@ -1805,6 +1832,7 @@ static const struct dma_ops udma_ops = {
.send = udma_send,
.receive= udma_receive,
.prepare_rcv_buf = udma_prepare_rcv_buf,
+ .get_cfg= udma_get_cfg,
};
static const struct udevice_id udma_ids[] = {
diff --git a/include/linux/soc/ti/ti-udma.h b/include/linux/soc/ti/ti-udma.h
index e9d4226c48d9..04e354fb2d69 100644
--- a/include/linux/soc/ti/ti-udma.h
+++ b/include/linux/soc/ti/ti-udma.h
@@ -21,4 +21,23 @@ struct ti_udma_drv_packet_data {
u32 dest_tag;
};
+/**
+ * struct ti_udma_drv_chan_cfg_data - TI UDMA per channel specific
+ * configuration data
+ *
+ * @flow_id_base: Start index of flow ID allocated to this channel
+ * @flow_id_cnt: Number of flows allocated for this channel starting at
+ * flow_id_base
+ *
+ * TI UDMA channel specific data returned as part of dma_get_cfg() call
+ * from the DMA client driver.
+ */
+struct ti_udma_drv_chan_cfg_data {
+ u32 flow_id_base;
+ u32 flow_id_cnt;
+};
+
+/* TI UDMA specific flag IDs for dma_get_cfg() call */
+#define TI_UDMA_CHAN_PRIV_INFO 0
+
#endif /* __TI_UDMA_H */
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] dma: Introduce dma_get_cfg() interface
Sometimes, there would be a need to exchange data between DMA provider
and DMA client which are very specific to DMA driver of the SoC/platform
and are not generic enough to be put into struct dma. Therefore, introduce
dma_get_cfg() interface to get DMA provider specific data from client
device. Clients can use unique configuration ID flags to get different
configuration data from DMA driver.
Signed-off-by: Vignesh Raghavendra
Acked-by: Joe Hershberger
---
drivers/dma/dma-uclass.c | 12
include/dma-uclass.h | 11 +++
include/dma.h| 11 +++
3 files changed, 34 insertions(+)
diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 9c961cf1e2c7..2321fb513ba3 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -186,6 +186,18 @@ int dma_send(struct dma *dma, void *src, size_t len, void
*metadata)
return ops->send(dma, src, len, metadata);
}
+
+int dma_get_cfg(struct dma *dma, u32 cfg_id, void **cfg_data)
+{
+ struct dma_ops *ops = dma_dev_ops(dma->dev);
+
+ debug("%s(dma=%p)\n", __func__, dma);
+
+ if (!ops->get_cfg)
+ return -ENOSYS;
+
+ return ops->get_cfg(dma, cfg_id, cfg_data);
+}
#endif /* CONFIG_DMA_CHANNELS */
int dma_get_device(u32 transfer_type, struct udevice **devp)
diff --git a/include/dma-uclass.h b/include/dma-uclass.h
index 31b43fb4b98e..a1d9d26ac56f 100644
--- a/include/dma-uclass.h
+++ b/include/dma-uclass.h
@@ -108,6 +108,17 @@ struct dma_ops {
* @return zero on success, or -ve error code.
*/
int (*send)(struct dma *dma, void *src, size_t len, void *metadata);
+ /**
+* get_cfg() - Get DMA channel configuration for client's use
+*
+* @dma:The DMA Channel to manipulate
+* @cfg_id: DMA provider specific ID to identify what
+* configuration data client needs
+* @data: Pointer to store pointer to DMA driver specific
+* configuration data for the given cfg_id (output param)
+* @return zero on success, or -ve error code.
+*/
+ int (*get_cfg)(struct dma *dma, u32 cfg_id, void **data);
#endif /* CONFIG_DMA_CHANNELS */
/**
* transfer() - Issue a DMA transfer. The implementation must
diff --git a/include/dma.h b/include/dma.h
index 32885571f7d4..426617b34edf 100644
--- a/include/dma.h
+++ b/include/dma.h
@@ -290,6 +290,17 @@ int dma_receive(struct dma *dma, void **dst, void
*metadata);
* @return zero on success, or -ve error code.
*/
int dma_send(struct dma *dma, void *src, size_t len, void *metadata);
+/**
+ * dma_get_cfg() - Get DMA channel configuration for client's use
+ *
+ * @dma: The DMA Channel to manipulate
+ * @cfg_id: DMA provider specific ID to identify what
+ *configuration data client needs
+ * @cfg_data: Pointer to store pointer to DMA driver specific
+ *configuration data for the given cfg_id (output param)
+ * @return zero on success, or -ve error code.
+ */
+int dma_get_cfg(struct dma *dma, u32 cfg_id, void **cfg_data);
#endif /* CONFIG_DMA_CHANNELS */
#if CONFIG_IS_ENABLED(DMA)
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] net: ti: am65-cpsw-nuss: Add new compatible for J721e
Add new compatible to handle J721e SoC
Signed-off-by: Vignesh Raghavendra
Acked-by: Joe Hershberger
---
drivers/dma/ti/k3-udma.c| 2 +-
drivers/net/ti/am65-cpsw-nuss.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 36bf349a8579..f398c5b4bbbd 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1837,7 +1837,7 @@ static const struct dma_ops udma_ops = {
static const struct udevice_id udma_ids[] = {
{ .compatible = "ti,k3-navss-udmap" },
- { .compatible = "ti,j721e-navss-main-udmap" },
+ { .compatible = "ti,j721e-navss-mcu-udmap" },
{ }
};
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 2e14f4be862f..b606ff0ade2a 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -772,6 +772,7 @@ out:
static const struct udevice_id am65_cpsw_nuss_ids[] = {
{ .compatible = "ti,am654-cpsw-nuss" },
+ { .compatible = "ti,j721e-cpsw-nuss" },
{ }
};
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] configs: j721e_evm_a72_defconfig: Enable DMA and Ethernet
Enable configs related to DMA and Ethernet so as to support networking at U-Boot prompt Signed-off-by: Vignesh Raghavendra Acked-by: Joe Hershberger --- configs/j721e_evm_a72_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 2112ce813be9..a73de0857734 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -51,6 +51,7 @@ CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-common-proc-board" CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y @@ -61,6 +62,8 @@ CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y +CONFIG_DMA_CHANNELS=y +CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y @@ -79,6 +82,10 @@ CONFIG_SYS_FLASH_CFI=y CONFIG_HBMC_AM654=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_TI=y +CONFIG_PHY_FIXED=y +CONFIG_DM_ETH=y +CONFIG_TI_AM65_CPSW_NUSS=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y @@ -93,6 +100,7 @@ CONFIG_RESET_TI_SCI=y CONFIG_SCSI=y CONFIG_DM_SCSI=y CONFIG_DM_SERIAL=y +CONFIG_SOC_TI=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_CADENCE_QSPI=y -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] J721e: Add networking support
This patch enables networking support for TI's J721e SoC. Patch 1 adds a new interface to DMA uclass to get channel specific private/configuration data. Patch 2 to 4 use this interface to pass data from J721e's UDMA driver to CPSW ethernet driver. Last two patches add DMA and CPSW DT nodes and configs. Depends on [1] for ethernet to work [1] http://patchwork.ozlabs.org/project/uboot/list/?series=145954 v2: Address comments from Grygorii. Collect Acks Vignesh Raghavendra (6): dma: Introduce dma_get_cfg() interface dma: ti: k3-udma: Implement dma_get_cfg() interface net: ti: am65-cpsw-nuss: Rework RX flow ID handling net: ti: am65-cpsw-nuss: Add new compatible for J721e arm: dts: k3-j721e-common-proc-board: Add DMA and CPSW related DT nodes configs: j721e_evm_a72_defconfig: Enable DMA and Ethernet .../k3-j721e-common-proc-board-u-boot.dtsi| 239 ++ configs/j721e_evm_a72_defconfig | 8 + drivers/dma/dma-uclass.c | 12 + drivers/dma/ti/k3-udma.c | 30 ++- drivers/net/ti/am65-cpsw-nuss.c | 14 +- include/dma-uclass.h | 11 + include/dma.h | 11 + include/linux/soc/ti/ti-udma.h| 19 ++ 8 files changed, 334 insertions(+), 10 deletions(-) -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] arm: dts: k3-j721e-common-proc-board: Add DMA and CPSW related DT nodes
Add DT nodes related to DMA and CPSW to -u-boot.dtsi to get networking
up on J721e EVM.
Signed-off-by: Vignesh Raghavendra
Acked-by: Joe Hershberger
---
.../k3-j721e-common-proc-board-u-boot.dtsi| 239 ++
1 file changed, 239 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 541da22c4889..f3857b9100bb 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -3,11 +3,18 @@
* Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
*/
+#include
+#include
+
/ {
chosen {
stdout-path = "serial2:115200n8";
tick-timer = &timer1;
};
+
+ aliases {
+ ethernet0 = &cpsw_port1;
+ };
};
&cbass_main{
@@ -24,6 +31,184 @@
clock-frequency = <2500>;
u-boot,dm-spl;
};
+
+ mcu_conf: scm_conf@40f0 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x0 0x40f0 0x0 0x2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x40f0 0x2>;
+
+ phy_sel: cpsw-phy-sel@4040 {
+ compatible = "ti,am654-cpsw-phy-sel";
+ reg = <0x4040 0x4>;
+ reg-names = "gmii-sel";
+ };
+ };
+
+ cbass_mcu_navss: mcu_navss {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-coherent;
+ dma-ranges;
+ ranges;
+
+ ti,sci-dev-id = <232>;
+ u-boot,dm-spl;
+
+ mcu_ringacc: ringacc@2b80 {
+ compatible = "ti,am654-navss-ringacc";
+ reg = <0x0 0x2b80 0x0 0x40>,
+ <0x0 0x2b00 0x0 0x40>,
+ <0x0 0x2859 0x0 0x100>,
+ <0x0 0x2a50 0x0 0x4>;
+ reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target";
+ ti,num-rings = <286>;
+ ti,sci-rm-range-gp-rings = <0x1>; /* GP ring range */
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <235>;
+ u-boot,dm-spl;
+ };
+
+ mcu_udmap: udmap@3115 {
+ compatible = "ti,j721e-navss-mcu-udmap";
+ reg = <0x0 0x285c 0x0 0x100>,
+ <0x0 0x2a80 0x0 0x4>,
+ <0x0 0x2aa0 0x0 0x4>;
+ reg-names = "gcfg", "rchanrt", "tchanrt";
+ #dma-cells = <3>;
+
+ ti,ringacc = <&mcu_ringacc>;
+ ti,psil-base = <0x6000>;
+
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <236>;
+
+ ti,sci-rm-range-tchan = <0x0d>, /* TX_CHAN */
+ <0x0f>; /* TX_HCHAN */
+ ti,sci-rm-range-rchan = <0x0a>, /* RX_CHAN */
+ <0x0b>; /* RX_HCHAN */
+ ti,sci-rm-range-rflow = <0x00>; /* GP RFLOW */
+ u-boot,dm-spl;
+ };
+ };
+
+ mcu_cpsw: ethernet@04600 {
+ compatible = "ti,j721e-cpsw-nuss";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ reg = <0x0 0x4600 0x0 0x20>;
+ reg-names = "cpsw_nuss";
+ ranges;
+ dma-coherent;
+ clocks = <&k3_clks 18 22>;
+ clock-names = "fck";
+ power-domains = <&k3_pds 18 TI_SCI_PD_EXCLUSIVE>;
+ ti,psil-base = <0x7000>;
+ cpsw-phy-sel = <&phy_sel>;
+
+ dmas = <&mcu_udmap &mcu_cpsw 0 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 1 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 2 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 3 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 4 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 5 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 6 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 7 UDMA_DIR_TX>,
+ <&mcu_udmap &mcu_cpsw 0 UDMA_DIR_RX>;
+ dma-names = "tx0", "tx1", "tx2", "tx3",
+ "tx4", "tx5", "tx6", "tx7",
+ "rx";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ host: host@0 {
+ reg = <0>;
+
[U-Boot] [PATCH v2 3/6] net: ti: am65-cpsw-nuss: Rework RX flow ID handling
Get flow ID information for RX DMA channel using dma_get_cfg() interface
instead of reading from DT. This is required in order to avoid DT update
whenever there is change in the range of flow ID allocated to the host.
Signed-off-by: Vignesh Raghavendra
Acked-by: Joe Hershberger
---
drivers/net/ti/am65-cpsw-nuss.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 06b06639506a..2e14f4be862f 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -99,7 +99,6 @@ struct am65_cpsw_common {
u32 port_num;
struct am65_cpsw_port ports[AM65_CPSW_CPSWNU_MAX_PORTS];
- u32 rflow_id_base;
struct mii_dev *bus;
u32 bus_freq;
@@ -276,6 +275,7 @@ static int am65_cpsw_start(struct udevice *dev)
struct am65_cpsw_common *common = priv->cpsw_common;
struct am65_cpsw_port *port = &common->ports[priv->port_id];
struct am65_cpsw_port *port0 = &common->ports[0];
+ struct ti_udma_drv_chan_cfg_data *dma_rx_cfg_data;
int ret, i;
ret = power_domain_on(&common->pwrdmn);
@@ -341,7 +341,8 @@ static int am65_cpsw_start(struct udevice *dev)
writel(PKTSIZE_ALIGN, port0->port_base + AM65_CPSW_PN_RX_MAXLEN_REG);
/* set base flow_id */
- writel(common->rflow_id_base,
+ dma_get_cfg(&common->dma_rx, 0, (void **)&dma_rx_cfg_data);
+ writel(dma_rx_cfg_data->flow_id_base,
port0->port_base + AM65_CPSW_P0_FLOW_ID_REG);
/* Reset and enable the ALE */
@@ -669,11 +670,6 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
AM65_CPSW_CPSW_NU_ALE_BASE;
cpsw_common->mdio_base = cpsw_common->ss_base + AM65_CPSW_MDIO_BASE;
- cpsw_common->rflow_id_base = 0;
- cpsw_common->rflow_id_base =
- dev_read_u32_default(dev, "ti,rx-flow-id-base",
-cpsw_common->rflow_id_base);
-
ports_np = dev_read_subnode(dev, "ports");
if (!ofnode_valid(ports_np)) {
ret = -ENOENT;
@@ -761,12 +757,11 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
if (ret)
goto out;
- dev_info(dev, "K3 CPSW: nuss_ver: 0x%08X cpsw_ver: 0x%08X ale_ver:
0x%08X Ports:%u rflow_id_base:%u mdio_freq:%u\n",
+ dev_info(dev, "K3 CPSW: nuss_ver: 0x%08X cpsw_ver: 0x%08X ale_ver:
0x%08X Ports:%u mdio_freq:%u\n",
readl(cpsw_common->ss_base),
readl(cpsw_common->cpsw_base),
readl(cpsw_common->ale_base),
cpsw_common->port_num,
-cpsw_common->rflow_id_base,
cpsw_common->bus_freq);
out:
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: pci: ignore disabled devices
On 12/1/2019 5:45 PM, Michael Walle wrote: PCI devices may be disabled in the device tree. Devices which are probed by the device tree handle the "status" property and are skipped if disabled. Devices which are probed by the PCI enumeration don't check that property. Fix it. Signed-off-by: Michael Walle --- drivers/pci/pci-uclass.c | 5 + 1 file changed, 5 insertions(+) Reviewed-by: Alex Marginean Tested-by: Alex Marginean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: pci: ignore disabled devices
On Mon, Dec 2, 2019 at 12:45 AM Michael Walle wrote: > > PCI devices may be disabled in the device tree. Devices which are probed > by the device tree handle the "status" property and are skipped if > disabled. Devices which are probed by the PCI enumeration don't check > that property. Fix it. > > Signed-off-by: Michael Walle > --- > drivers/pci/pci-uclass.c | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH v2] spl: Introduce SPL_DM_GPIO Kconfig define
This define indicates if DM_GPIO shall be supported in SPL. This allows proper operation of DM converted GPIO drivers in SPL, which use boards. Signed-off-by: Lukasz Majewski --- Changes in v2: - Add dependency on DM_GPIO Note: - Board which is using DM_GPIO in SPL with OF_PLATDATA (XEA - i.MX28) depends on this Kconfig define. Only after it is in - it can be added without compiler errors. --- common/spl/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 1f122833a7..239cb4440e 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -485,6 +485,12 @@ config SPL_DMA_SUPPORT the CPU moving the data. Enable this option to build the drivers in drivers/dma as part of an SPL build. +config SPL_DM_GPIO + bool "Support Driver Model GPIO drivers" + depends on SPL_GPIO_SUPPORT && DM_GPIO + help + Enable support for Driver Model based GPIO drivers in SPL. + config SPL_DRIVERS_MISC_SUPPORT bool "Support misc drivers" help -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] omapl138_lcdk: fix MMC boot
czw., 14 lis 2019 o 16:10 Bartosz Golaszewski napisał(a): > > From: Bartosz Golaszewski > > Booting from MMC on omapl138-lcdk is currently broken after we enabled > driver-model in SPL. While I know what's wrong - the bind() callback not > being called - I can't for the life of me figure out how to fix it. > > I'm still working on proper changes, but for now, I'd like to propose > this series which fixes MMC boot with a workaround in which we call > mmc_boot() manually from probe. > > First two patches drop some legacy code that's no longer needed. The > third patch adds a U_BOOT_DEVICE() for mmc as we don't yet have full > DT support (also in-progress). The last patch adds the workaround to > the davinci mmc driver. > > This series depends on Adam Ford's patch increasing the pre-reloc > malloc pool. > > [1] https://patchwork.ozlabs.org/patch/1192574/ > > Bartosz Golaszewski (4): > mmc: davinci: drop support for ti,dm6441-mmc > mmc: davinci: drop struct davinci_mmc_plat > board: omapl138_lcdk: add the mmc device to SPL > mmc: davinci: fix mmc boot in SPL > > arch/arm/mach-davinci/Kconfig | 1 + > .../mach-davinci/include/mach/sdmmc_defs.h| 6 -- > board/davinci/da8xxevm/omapl138_lcdk.c| 10 ++- > drivers/mmc/davinci_mmc.c | 73 +++ > 4 files changed, 36 insertions(+), 54 deletions(-) > > -- > 2.23.0 > Gentle ping. Bart ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Kuldeep,
On 29.11.19 06:54, Kuldeep Singh wrote:
This entire patch series migrate freescale qspi driver to spi-mem framework.
Patch 1 removes the old fsl qspi driver
Patch 2 adds new qspi driver incorporating spi-mem framework which is ported
version of linux qspi driver. Initial port was done by Frieder. Now, no more
direct access to spi-nor memory is possible. Few changes were introduced to
prevent uboot crash such as to add complete flash size to SFA1AD, SFA2AD,
SFB1AD, SFB2AD based on chip select number instead of 1k. Immediate effect was
observed on pfe while using 1k size as it access spi-nor memory directly. Using
complete flash size resolves the crash but data read will not be valid.
Patch 3 removes unused config options.
Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header files.
SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR.
Patch 5 removes unused num-cs property for imx platforms
Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR is no longer
required and can be removed.
Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files. While
enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR at the same time.
Patch 8 updates the device-tree properties treewide for layerscape boards by
aligning it with linux device-tree properties.
Many thanks for working on this. I've tested this patchset on a new
i-MX6ULL/ULZ based board and noticed, that I still need to add this
kind of patch to make it work on my platform:
drivers/spi/fsl_qspi.c
index 788fa0416f..0946f9d6d5 100644
@@ -44,6 +44,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define QUADSPI_IPCR 0x08
#define QUADSPI_IPCR_SEQID(x) ((x) << 24)
+#define QUADSPI_FLSHCR 0x0c
+#define QUADSPI_FLSHCR_TDH(x) ((x) << 16)
+
#define QUADSPI_BUF3CR 0x1c
#define QUADSPI_BUF3CR_ALLMST_MASK BIT(31)
#define QUADSPI_BUF3CR_ADATSZ(x) ((x) << 8)
@@ -666,6 +669,16 @@ static int fsl_qspi_default_setup(struct fsl_qspi *q)
QUADSPI_BUF3CR_ADATSZ(q->devtype_data->ahb_buf_size / 8),
base + QUADSPI_BUF3CR);
+ /*
+* Clear THD bits to configure SDR mode instead of DDR mode. This
+* might be necessary, as the BootROM in some versions and on some
+* SoCs sets these bits to 0x1 for DDR mode. But this driver needs
+* it set to SDR mode instead.
+*/
+ reg = qspi_readl(q, base + QUADSPI_FLSHCR);
+ reg &= ~QUADSPI_FLSHCR_TDH(0x3);
+ qspi_writel(q, reg, base + QUADSPI_FLSHCR);
This was suggested by Frieder and is also integrated in the Linux
QSPI driver:
Commit ID f6910679e17a ("spi: spi-fsl-qspi: Clear TDH bits in FLSHCR
register")
What is the status of SDR vs DDR mode in this driver? Is this driver
version supposed to handle DDR mode correctly? If not, could you
please integrate this patch (or Frieder's Linux patch) into your
patchset so that the driver also works on i.MX6ULL/ULZ ?
Thanks,
Stefan
Frieder Schrempf (1):
imx: imx6sx: Remove unused 'num-cs' property
Kuldeep Singh (7):
spi: Remove old freescale qspi driver
spi: Transform the FSL QuadSPI driver to use the SPI MEM API
treewide: Remove unused FSL QSPI config options
configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig
configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
treewide: Update fsl qspi node dt properties as per spi-mem driver
arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +-
arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +-
arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +-
arch/arm/dts/fsl-ls1012a.dtsi |4 +-
arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +-
arch/arm/dts/fsl-ls1043a.dtsi |6 +-
arch/arm/dts/fsl-ls1046a-frwy.dts |5 +-
arch/arm/dts/fsl-ls1046a-qds.dtsi |5 +-
arch/arm/dts/fsl-ls1046a-rdb.dts |5 +-
arch/arm/dts/fsl-ls1046a.dtsi |4 +-
arch/arm/dts/fsl-ls1088a-qds.dts |5 +-
arch/arm/dts/fsl-ls1088a-rdb.dts |5 +-
arch/arm/dts/fsl-ls1088a.dtsi |2 +-
arch/arm/dts/fsl-ls2080a-qds.dts |5 +-
arch/arm/dts/fsl-ls2080a.dtsi |4 +-
arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |5 +-
arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi |2 -
arch/arm/dts/imx6sx-sdb-u-boot.dtsi |2 -
arch/arm/dts/ls1021a-twr.dtsi |5 +-
arch/arm/dts/ls1021a.dtsi |6 +-
.../include/asm/arch-fsl-layerscape/config.h |1 -
arch/arm/include/asm/arch-ls102xa/config.h|1 -
configs/ls1012aqds_qspi_defconfig |2 +-
configs/ls1012aqds_tfa_defconfig |2 +-
configs/ls1012ardb_qspi_SECURE_BOOT_def
[U-Boot] [PATCH] rockchip: config: add support for firefly-px30 board
This is a core board named Core-PX30-JD4 with a mainboard from Firefly, name it as firefly-px30 for now. This board can re-use the dts of PX30, the only difference is the UART IO, the firefly use UART2 M1 while evb use UART2 M0. Signed-off-by: Kever Yang --- board/rockchip/evb_px30/MAINTAINERS | 1 + configs/firefly-px30_defconfig | 113 2 files changed, 114 insertions(+) create mode 100644 configs/firefly-px30_defconfig diff --git a/board/rockchip/evb_px30/MAINTAINERS b/board/rockchip/evb_px30/MAINTAINERS index cf13f2419e..4dc060c501 100644 --- a/board/rockchip/evb_px30/MAINTAINERS +++ b/board/rockchip/evb_px30/MAINTAINERS @@ -4,3 +4,4 @@ S: Maintained F: board/rockchip/evb_px30 F: include/configs/evb_px30.h F: configs/evb-px30_defconfig +F: configs/firefly-px30_defconfig diff --git a/configs/firefly-px30_defconfig b/configs/firefly-px30_defconfig new file mode 100644 index 00..fa4ac75b09 --- /dev/null +++ b/configs/firefly-px30_defconfig @@ -0,0 +1,113 @@ +CONFIG_ARM=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_ROCKCHIP_PX30=y +CONFIG_TARGET_EVB_PX30=y +CONFIG_TPL_LIBGENERIC_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_SPL_STACK_R_ADDR=0x60 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_DEBUG_UART_BASE=0xFF16 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_DEBUG_UART=y +CONFIG_SPL_TEXT_BASE=0x +CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 +# CONFIG_ANDROID_BOOT_IMAGE is not set +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +# CONFIG_CONSOLE_MUX is not set +CONFIG_DEFAULT_FDT_FILE="rockchip/px30-evb.dtb" +CONFIG_MISC_INIT_R=y +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SPL_BOOTROM_SUPPORT=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_STACK_R=y +# CONFIG_TPL_BANNER_PRINT is not set +CONFIG_SPL_CRC32_SUPPORT=y +CONFIG_SPL_ATF=y +# CONFIG_TPL_FRAMEWORK is not set +# CONFIG_CMD_BOOTD is not set +CONFIG_DEBUG_UART2_CHANNEL=1 +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set +# CONFIG_CMD_LZMADEC is not set +# CONFIG_CMD_UNZIP is not set +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPT=y +# CONFIG_CMD_LOADB is not set +# CONFIG_CMD_LOADS is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y +# CONFIG_CMD_ITEST is not set +# CONFIG_CMD_SETEXPR is not set +# CONFIG_CMD_MISC is not set +# CONFIG_SPL_DOS_PARTITION is not set +# CONFIG_ISO_PARTITION is not set +CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 +CONFIG_SPL_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_DEFAULT_DEVICE_TREE="px30-evb" +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_REGMAP=y +CONFIG_SPL_REGMAP=y +CONFIG_SYSCON=y +CONFIG_SPL_SYSCON=y +CONFIG_CLK=y +CONFIG_SPL_CLK=y +CONFIG_FASTBOOT_BUF_ADDR=0x800800 +CONFIG_FASTBOOT_BUF_SIZE=0x0400 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 +CONFIG_ROCKCHIP_GPIO=y +CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y +CONFIG_ROCKCHIP_OTP=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_PHY_REALTEK=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_GMAC_ROCKCHIP=y +CONFIG_PINCTRL=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_RK8XX=y +CONFIG_REGULATOR_PWM=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_ROCKCHIP_SDRAM_COMMON=y +CONFIG_DM_RESET=y +# CONFIG_SPECIFY_CONSOLE_INDEX is not set +# CONFIG_TPL_DM_SERIAL is not set +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_DEBUG_UART_SKIP_INIT=y +CONFIG_SOUND=y +CONFIG_SYSRESET=y +CONFIG_OPTEE=y +CONFIG_DM_THERMAL=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_DM_VIDEO=y +CONFIG_DISPLAY=y +CONFIG_LCD=y +CONFIG_SPL_TINY_MEMSET=y +CONFIG_TPL_TINY_MEMSET=y +CONFIG_LZ4=y +CONFIG_LZO=y +CONFIG_ERRNO_STR=y +# CONFIG_EFI_LOADER is not set -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
From: "Ang, Chee Hong" New U-boot flow with ARM Trusted Firmware (ATF) support: SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) SPL loads the u-boot.itb which consist of: 1) u-boot-nodtb.bin (U-Boot Proper image) 2) u-boot.dtb (U-Boot Proper DTB) 3) bl31.bin (ATF-BL31 image) Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) Now, U-Boot Proper is running in non-secure mode (EL2), it invokes SMC/PSCI calls provided by ATF to perform COLD reset, System Manager register accesses and mailbox communications with Secure Device Manager (SDM). Steps to build the U-Boot with ATF support: 1) Build U-Boot 2) Build ATF BL31 3) Copy ATF BL31 binary image into U-Boot's root folder 4) "make u-boot.itb" to generate u-boot.itb These patchsets have dependency on: [U-Boot,v8,00/19] Add Intel Agilex SoC support: https://patchwork.ozlabs.org/cover/1201373/ Chee Hong Ang (19): arm: socfpga: add fit source file for pack itb with ATF arm: socfpga: Add function for checking description from FIT image arm: socfpga: Load FIT image with ATF support arm: socfpga: Override 'lowlevel_init' to support ATF configs: socfpga: Enable FIT image loading with ATF support arm: socfpga: Disable "spin-table" method for booting Linux arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) arm: socfpga: Define SMC function identifiers for PSCI SiP services arm: socfpga: Add secure register access helper functions for SoC 64bits arm: socfpga: Secure register access for clock manager (SoC 64bits) arm: socfpga: Secure register access in PHY mode setup arm: socfpga: Secure register access for reading PLL frequency mmc: dwmmc: socfpga: Secure register access in MMC driver net: designware: socfpga: Secure register access in MAC driver arm: socfpga: Secure register access in Reset Manager driver arm: socfpga: stratix10: Initialize timer in SPL arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config status sysreset: socfpga: Invoke PSCI call for COLD reset Dalon Westergreen (1): configs: stratix10: Remove CONFIG_OF_EMBED arch/arm/mach-socfpga/Kconfig | 2 - arch/arm/mach-socfpga/Makefile | 4 + arch/arm/mach-socfpga/board.c | 10 + arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- arch/arm/mach-socfpga/clock_manager_s10.c | 5 +- arch/arm/mach-socfpga/include/mach/misc.h | 3 + .../mach-socfpga/include/mach/secure_reg_helper.h | 20 ++ arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ arch/arm/mach-socfpga/misc_s10.c | 47 ++- arch/arm/mach-socfpga/reset_manager_s10.c | 31 +- arch/arm/mach-socfpga/secure_reg_helper.c | 67 arch/arm/mach-socfpga/timer_s10.c | 3 +- arch/arm/mach-socfpga/wrap_pll_config_s10.c| 9 +- board/altera/soc64/its/fit_spl_atf.its | 51 +++ configs/socfpga_agilex_defconfig | 8 +- configs/socfpga_stratix10_defconfig| 9 +- drivers/fpga/stratix10.c | 261 -- drivers/mmc/socfpga_dw_mmc.c | 7 +- drivers/net/dwmac_socfpga.c| 5 +- drivers/sysreset/sysreset_socfpga_s10.c| 4 +- include/configs/socfpga_soc64_common.h | 2 +- include/linux/intel-smc.h | 374 + 22 files changed, 732 insertions(+), 243 deletions(-) create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c create mode 100644 board/altera/soc64/its/fit_spl_atf.its create mode 100644 include/linux/intel-smc.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 01/20] configs: stratix10: Remove CONFIG_OF_EMBED
From: Dalon Westergreen CONFIG_OF_EMBED was primarily enabled to support the stratix10 spl hex file requirements. Since this option now produces a warning during build, and the spl hex can be created using alternate methods, CONFIG_OF_EMBED is no longer needed. Signed-off-by: Dalon Westergreen Signed-off-by: Chee Hong Ang --- configs/socfpga_stratix10_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig index e41588b..903d17b 100644 --- a/configs/socfpga_stratix10_defconfig +++ b/configs/socfpga_stratix10_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 04/20] arm: socfpga: Load FIT image with ATF support
From: Chee Hong Ang Instead of loading u-boot proper image (u-boot.img), SPL now loads FIT image (u-boot.itb) which includes u-boot proper, ATF and u-boot proper's DTB. Signed-off-by: Chee Hong Ang --- include/configs/socfpga_soc64_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/socfpga_soc64_common.h b/include/configs/socfpga_soc64_common.h index 4b27483..28ab014 100644 --- a/include/configs/socfpga_soc64_common.h +++ b/include/configs/socfpga_soc64_common.h @@ -198,6 +198,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void); /* SPL SDMMC boot support */ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.itb" #endif /* __CONFIG_SOCFPGA_SOC64_COMMON_H__ */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 05/20] arm: socfpga: Override 'lowlevel_init' to support ATF
From: Chee Hong Ang Override 'lowlevel_init' to support booting ATF from SPL on Intel SOCFPGA (64bits) platforms. Signed-off-by: Chee Hong Ang --- arch/arm/mach-socfpga/Makefile| 2 ++ arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ 2 files changed, 50 insertions(+) create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile index 418f543..3310e92 100644 --- a/arch/arm/mach-socfpga/Makefile +++ b/arch/arm/mach-socfpga/Makefile @@ -29,6 +29,7 @@ endif ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 obj-y += clock_manager_s10.o +obj-y += lowlevel_init.o obj-y += mailbox_s10.o obj-y += misc_s10.o obj-y += mmu-arm64_s10.o @@ -41,6 +42,7 @@ endif ifdef CONFIG_TARGET_SOCFPGA_AGILEX obj-y += clock_manager_agilex.o +obj-y += lowlevel_init.o obj-y += mailbox_s10.o obj-y += misc_s10.o obj-y += mmu-arm64_s10.o diff --git a/arch/arm/mach-socfpga/lowlevel_init.S b/arch/arm/mach-socfpga/lowlevel_init.S new file mode 100644 index 000..2fb2f3c --- /dev/null +++ b/arch/arm/mach-socfpga/lowlevel_init.S @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2019, Intel Corporation + */ + +#include +#include +#include +#include + +ENTRY(lowlevel_init) + mov x29, lr /* Save LR */ + +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) + branch_if_slave x0, 2f + + ldr x0, =GICD_BASE + bl gic_init_secure +#ifdef CONFIG_SPL_BUILD + b 2f +#else + b 3f +#endif + +#if defined(CONFIG_GICV3) + ldr x0, =GICR_BASE + bl gic_init_secure_percpu +#elif defined(CONFIG_GICV2) + ldr x0, =GICD_BASE + ldr x1, =GICC_BASE + bl gic_init_secure_percpu +#endif +#endif + +2: +#ifdef CONFIG_SPL_BUILD + ldr x4, =CPU_RELEASE_ADDR + ldr x5, [x4] + cbz x5, checkslavecpu + br x5 +checkslavecpu: + branch_if_slave x0, 2b +#endif + +3: + mov lr, x29 /* Restore LR */ + ret +ENDPROC(lowlevel_init) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 11/20] arm: socfpga: Secure register access for clock manager (SoC 64bits)
From: Chee Hong Ang
Allow clock manager driver to access the System Manager's Boot
Scratch Register 0 in non-secure mode (EL2) on SoC 64bits platform.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +++--
arch/arm/mach-socfpga/clock_manager_s10.c| 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-socfpga/clock_manager_agilex.c
b/arch/arm/mach-socfpga/clock_manager_agilex.c
index 791066d..3a2c80f 100644
--- a/arch/arm/mach-socfpga/clock_manager_agilex.c
+++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -64,8 +65,8 @@ unsigned int cm_get_l4_sys_free_clk_hz(void)
u32 cm_get_qspi_controller_clk_hz(void)
{
- return readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
+ return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
}
void cm_print_clock_quick_summary(void)
diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c
b/arch/arm/mach-socfpga/clock_manager_s10.c
index 05e4212..02578cc 100644
--- a/arch/arm/mach-socfpga/clock_manager_s10.c
+++ b/arch/arm/mach-socfpga/clock_manager_s10.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -385,8 +386,8 @@ unsigned int cm_get_l4_sp_clk_hz(void)
unsigned int cm_get_qspi_controller_clk_hz(void)
{
- return readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
+ return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
}
unsigned int cm_get_spi_controller_clk_hz(void)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 02/20] arm: socfpga: add fit source file for pack itb with ATF
From: Chee Hong Ang
Generate a FIT image for Intel SOCFPGA(64bits) which
include U-boot proper, ATF and DTB for U-boot proper.
Signed-off-by: Chee Hong Ang
---
board/altera/soc64/its/fit_spl_atf.its | 51 ++
1 file changed, 51 insertions(+)
create mode 100644 board/altera/soc64/its/fit_spl_atf.its
diff --git a/board/altera/soc64/its/fit_spl_atf.its
b/board/altera/soc64/its/fit_spl_atf.its
new file mode 100644
index 000..bbc6a86
--- /dev/null
+++ b/board/altera/soc64/its/fit_spl_atf.its
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2019 Intel Corporation. All rights reserved
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/dts-v1/;
+
+/ {
+ description = "FIT image with U-Boot proper, ATF bl31, DTB";
+ #address-cells = <1>;
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ data = /incbin/("../../../../u-boot-nodtb.bin");
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm64";
+ compression = "none";
+ load = <0x0020>;
+ };
+ atf {
+ description = "ARM Trusted Firmware";
+ data = /incbin/("../../../../bl31.bin");
+ type = "firmware";
+ os = "arm-trusted-firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x1000>;
+ entry = <0x1000>;
+ };
+
+ fdt {
+ description = "Stratix 10 flat device-tree";
+ data = /incbin/("../../../../u-boot.dtb");
+ type = "flat_dt";
+ compression = "none";
+ };
+ };
+
+ configurations {
+ default = "conf";
+ conf {
+ description = "Intel Stratix 10";
+ firmware = "atf";
+ loadables = "uboot";
+ fdt = "fdt";
+ };
+ };
+};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 03/20] arm: socfpga: Add function for checking description from FIT image
From: Chee Hong Ang
Add board_fit_config_name_match() for matching board name with
device tree files in FIT image. This will ensure correct DTB
file is loaded for different board type. Currently, we are not
supporting multiple device tree files in FIT image therefore this
function basically do nothing for now.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/board.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 7c8c05c..1830e2c 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -86,3 +86,13 @@ int g_dnl_board_usb_cable_connected(void)
return 1;
}
#endif
+
+#ifdef CONFIG_SPL_BUILD
+int board_fit_config_name_match(const char *name)
+{
+ /* Just empty function now - can't decide what to choose */
+ debug("%s: %s\n", __func__, name);
+
+ return 0;
+}
+#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 16/20] arm: socfpga: Secure register access in Reset Manager driver
From: Chee Hong Ang
Allow socfpga_bridges_reset() function in Reset Manager driver to
access System Manager's register in non-secure mode (EL2).
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/reset_manager_s10.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c
b/arch/arm/mach-socfpga/reset_manager_s10.c
index c743077..d03f121 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -56,34 +57,37 @@ void socfpga_bridges_reset(int enable)
{
if (enable) {
/* clear idle request to all bridges */
- setbits_le32(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_NOC_IDLEREQ_CLR, ~0);
+ socfpga_secure_reg_update32(socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_IDLEREQ_CLR,
+ ~0, ~0);
/* Release all bridges from reset state */
clrbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_SOC64_BRGMODRST,
~0);
/* Poll until all idleack to 0 */
- while (readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_NOC_IDLEACK))
+ while (socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_NOC_IDLEACK))
;
} else {
/* set idle request to all bridges */
- writel(~0,
- socfpga_get_sysmgr_addr() +
- SYSMGR_SOC64_NOC_IDLEREQ_SET);
+ socfpga_secure_reg_write32(~0, socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_IDLEREQ_SET);
/* Enable the NOC timeout */
- writel(1, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
+ socfpga_secure_reg_write32(1, socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_TIMEOUT);
/* Poll until all idleack to 1 */
- while ((readl(socfpga_get_sysmgr_addr() +
SYSMGR_SOC64_NOC_IDLEACK) ^
- (SYSMGR_NOC_H2F_MSK | SYSMGR_NOC_LWH2F_MSK)))
+ while ((socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_IDLEACK) ^ (SYSMGR_NOC_H2F_MSK |
+ SYSMGR_NOC_LWH2F_MSK)))
;
/* Poll until all idlestatus to 1 */
- while ((readl(socfpga_get_sysmgr_addr() +
SYSMGR_SOC64_NOC_IDLESTATUS) ^
- (SYSMGR_NOC_H2F_MSK | SYSMGR_NOC_LWH2F_MSK)))
+ while ((socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_IDLESTATUS) ^ (SYSMGR_NOC_H2F_MSK |
+ SYSMGR_NOC_LWH2F_MSK)))
;
/* Reset all bridges (except NOR DDR scheduler & F2S) */
@@ -92,7 +96,8 @@ void socfpga_bridges_reset(int enable)
RSTMGR_BRGMODRST_FPGA2SOC_MASK));
/* Disable NOC timeout */
- writel(0, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
+ socfpga_secure_reg_write32(0, socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_TIMEOUT);
}
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 17/20] arm: socfpga: stratix10: Initialize timer in SPL
From: Chee Hong Ang
Initialize timer in SPL running in secure mode (EL3)
and skip timer initialization in U-Boot proper running in
non-secure mode (EL2).
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/timer_s10.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/timer_s10.c
b/arch/arm/mach-socfpga/timer_s10.c
index 5723789..0fa56c3 100644
--- a/arch/arm/mach-socfpga/timer_s10.c
+++ b/arch/arm/mach-socfpga/timer_s10.c
@@ -13,6 +13,7 @@
*/
int timer_init(void)
{
+#ifdef CONFIG_SPL_BUILD
int enable = 0x3; /* timer enable + output signal masked */
int loadval = ~0;
@@ -21,6 +22,6 @@ int timer_init(void)
/* enable processor pysical counter */
asm volatile("msr cntp_ctl_el0, %0" : : "r" (enable));
asm volatile("msr cntp_tval_el0, %0" : : "r" (loadval));
-
+#endif
return 0;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 09/20] arm: socfpga: Define SMC function identifiers for PSCI SiP services
From: Chee Hong Ang This header file defines the Secure Monitor Call (SMC) message protocol for ATF (BL31) PSCI runtime services. It includes all the PSCI SiP function identifiers for the secure runtime services provided by ATF. The secure runtime services include System Manager's registers access, 2nd phase bitstream FPGA reconfiguration, Remote System Update (RSU) and etc. Signed-off-by: Chee Hong Ang --- include/linux/intel-smc.h | 374 ++ 1 file changed, 374 insertions(+) create mode 100644 include/linux/intel-smc.h diff --git a/include/linux/intel-smc.h b/include/linux/intel-smc.h new file mode 100644 index 000..27710ac --- /dev/null +++ b/include/linux/intel-smc.h @@ -0,0 +1,374 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2017-2018, Intel Corporation + */ + +#ifndef __INTEL_SMC_H +#define __INTEL_SMC_H + +#include +#include + +/* + * This file defines the Secure Monitor Call (SMC) message protocol used for + * service layer driver in normal world (EL1) to communicate with secure + * monitor software in Secure Monitor Exception Level 3 (EL3). + * + * This file is shared with secure firmware (FW) which is out of kernel tree. + * + * An ARM SMC instruction takes a function identifier and up to 6 64-bit + * register values as arguments, and can return up to 4 64-bit register + * value. The operation of the secure monitor is determined by the parameter + * values passed in through registers. + + * EL1 and EL3 communicates pointer as physical address rather than the + * virtual address. + */ + +/* + * Functions specified by ARM SMC Calling convention: + * + * FAST call executes atomic operations, returns when the requested operation + * has completed. + * STD call starts a operation which can be preempted by a non-secure + * interrupt. The call can return before the requested operation has + * completed. + * + * a0..a7 is used as register names in the descriptions below, on arm32 + * that translates to r0..r7 and on arm64 to w0..w7. + */ + +#define INTEL_SIP_SMC_STD_CALL_VAL(func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_64, \ + ARM_SMCCC_OWNER_SIP, (func_num)) + +#define INTEL_SIP_SMC_FAST_CALL_VAL(func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \ + ARM_SMCCC_OWNER_SIP, (func_num)) + +/* + * Return values in INTEL_SIP_SMC_* call + * + * INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION: + * Secure monitor software doesn't recognize the request. + * + * INTEL_SIP_SMC_STATUS_OK: + * FPGA configuration completed successfully, + * In case of FPGA configuration write operation, it means secure monitor + * software can accept the next chunk of FPGA configuration data. + * + * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY: + * In case of FPGA configuration write operation, it means secure monitor + * software is still processing previous data & can't accept the next chunk + * of data. Service driver needs to issue + * INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE call to query the + * completed block(s). + * + * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR: + * There is error during the FPGA configuration process. + * + * INTEL_SIP_SMC_REG_ERROR: + * There is error during a read or write operation of the protected + * registers. + */ +#define INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION 0x +#define INTEL_SIP_SMC_STATUS_OK0x0 +#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY 0x1 +#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_REJECTED 0x2 +#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR 0x4 +#define INTEL_SIP_SMC_REG_ERROR0x5 +#define INTEL_SIP_SMC_RSU_ERROR0x7 + +/* + * Request INTEL_SIP_SMC_FPGA_CONFIG_START + * + * Sync call used by service driver at EL1 to request the FPGA in EL3 to + * be prepare to receive a new configuration. + * + * Call register usage: + * a0: INTEL_SIP_SMC_FPGA_CONFIG_START. + * a1: flag for full or partial configuration + *0 full reconfiguration. + *1 partial reconfiguration. + * a2-7: not used. + * + * Return status: + * a0: INTEL_SIP_SMC_STATUS_OK, or INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR. + * a1-3: not used. + */ +#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START 1 +#define INTEL_SIP_SMC_FPGA_CONFIG_START \ + INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START) + +/* + * Request INTEL_SIP_SMC_FPGA_CONFIG_WRITE + * + * Async call used by service driver at EL1 to provide FPGA configuration data + * to secure world. + * + * Call register usage: + * a0: INTEL_SIP_SMC_FPGA_CONFIG_WRITE. + * a1: 64bit physical address of the configuration data memory block + * a2: Size of configuration data block. + * a3-7: not used. + * + * Return status: + * a0: INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY or + * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR. + * a1: 64bit physical address of 1st completed memory block if any completed
[U-Boot] [PATCH v1 18/20] arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
From: Chee Hong Ang
Refactor the FPGA recpnfiguration driver to call the ATF's PSCI
runtime services as it no longer handles the Secure Device Manager
(SDM) mailbox communication and FPGA reconfiguration logic.
Signed-off-by: Chee Hong Ang
---
drivers/fpga/stratix10.c | 261 +++
1 file changed, 59 insertions(+), 202 deletions(-)
diff --git a/drivers/fpga/stratix10.c b/drivers/fpga/stratix10.c
index d8e3250..44a427d 100644
--- a/drivers/fpga/stratix10.c
+++ b/drivers/fpga/stratix10.c
@@ -2,92 +2,16 @@
/*
* Copyright (C) 2018 Intel Corporation
*/
-
#include
#include
-#include
+#include
+#include
+
+#define BITSTREAM_CHUNK_SIZE 0x0
#define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS 6
#define RECONFIG_STATUS_INTERVAL_DELAY_US 100
-
-static const struct mbox_cfgstat_state {
- int err_no;
- const char *error_name;
-} mbox_cfgstat_state[] = {
- {MBOX_CFGSTAT_STATE_IDLE, "FPGA in idle mode."},
- {MBOX_CFGSTAT_STATE_CONFIG, "FPGA in config mode."},
- {MBOX_CFGSTAT_STATE_FAILACK, "Acknowledgment failed!"},
- {MBOX_CFGSTAT_STATE_ERROR_INVALID, "Invalid bitstream!"},
- {MBOX_CFGSTAT_STATE_ERROR_CORRUPT, "Corrupted bitstream!"},
- {MBOX_CFGSTAT_STATE_ERROR_AUTH, "Authentication failed!"},
- {MBOX_CFGSTAT_STATE_ERROR_CORE_IO, "I/O error!"},
- {MBOX_CFGSTAT_STATE_ERROR_HARDWARE, "Hardware error!"},
- {MBOX_CFGSTAT_STATE_ERROR_FAKE, "Fake error!"},
- {MBOX_CFGSTAT_STATE_ERROR_BOOT_INFO, "Error in boot info!"},
- {MBOX_CFGSTAT_STATE_ERROR_QSPI_ERROR, "Error in QSPI!"},
- {MBOX_RESP_ERROR, "Mailbox general error!"},
- {-ETIMEDOUT, "I/O timeout error"},
- {-1, "Unknown error!"}
-};
-
-#define MBOX_CFGSTAT_MAX ARRAY_SIZE(mbox_cfgstat_state)
-
-static const char *mbox_cfgstat_to_str(int err)
-{
- int i;
-
- for (i = 0; i < MBOX_CFGSTAT_MAX - 1; i++) {
- if (mbox_cfgstat_state[i].err_no == err)
- return mbox_cfgstat_state[i].error_name;
- }
-
- return mbox_cfgstat_state[MBOX_CFGSTAT_MAX - 1].error_name;
-}
-
-/*
- * Add the ongoing transaction's command ID into pending list and return
- * the command ID for next transfer.
- */
-static u8 add_transfer(u32 *xfer_pending_list, size_t list_size, u8 id)
-{
- int i;
-
- for (i = 0; i < list_size; i++) {
- if (xfer_pending_list[i])
- continue;
- xfer_pending_list[i] = id;
- debug("ID(%d) added to transaction pending list\n", id);
- /*
-* Increment command ID for next transaction.
-* Valid command ID (4 bits) is from 1 to 15.
-*/
- id = (id % 15) + 1;
- break;
- }
-
- return id;
-}
-
-/*
- * Check whether response ID match the command ID in the transfer
- * pending list. If a match is found in the transfer pending list,
- * it clears the transfer pending list and return the matched
- * command ID.
- */
-static int get_and_clr_transfer(u32 *xfer_pending_list, size_t list_size,
- u8 id)
-{
- int i;
-
- for (i = 0; i < list_size; i++) {
- if (id != xfer_pending_list[i])
- continue;
- xfer_pending_list[i] = 0;
- return id;
- }
-
- return 0;
-}
+#define RECONFIG_STATUS_POLL_RETRY_MAX 100
/*
* Polling the FPGA configuration status.
@@ -99,11 +23,13 @@ static int reconfig_status_polling_resp(void)
unsigned long start = get_timer(0);
while (1) {
- ret = mbox_get_fpga_config_status(MBOX_RECONFIG_STATUS);
+ ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+NULL, 0);
+
if (!ret)
return 0; /* configuration success */
- if (ret != MBOX_CFGSTAT_STATE_CONFIG)
+ if (ret != INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY)
return ret;
if (get_timer(start) > RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS)
@@ -116,125 +42,59 @@ static int reconfig_status_polling_resp(void)
return -ETIMEDOUT;
}
-static u32 get_resp_hdr(u32 *r_index, u32 *w_index, u32 *resp_count,
- u32 *resp_buf, u32 buf_size, u32 client_id)
-{
- u32 buf[MBOX_RESP_BUFFER_SIZE];
- u32 mbox_hdr;
- u32 resp_len;
- u32 hdr_len;
- u32 i;
-
- if (*resp_count < buf_size) {
- u32 rcv_len_max = buf_size - *resp_count;
-
- if (rcv_len_max > MBOX_RESP_BUFFER_SIZE)
- rcv_len_max = MBOX_RESP_BUFFER_SIZE;
- resp_len = mbox_rcv_resp(buf, rcv_len_max);
-
- for (i = 0; i < resp_len; i++) {
-
[U-Boot] [PATCH v1 15/20] net: designware: socfpga: Secure register access in MAC driver
From: Chee Hong Ang
Allow MAC driver to access System Manager's EMAC control
registers in non-secure mode.
Signed-off-by: Chee Hong Ang
---
drivers/net/dwmac_socfpga.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
index b7bf5db..ae747ca 100644
--- a/drivers/net/dwmac_socfpga.c
+++ b/drivers/net/dwmac_socfpga.c
@@ -16,6 +16,7 @@
#include "designware.h"
#include
+#include
struct dwmac_socfpga_platdata {
struct dw_eth_pdata dw_eth_pdata;
@@ -96,8 +97,8 @@ static int dwmac_socfpga_probe(struct udevice *dev)
reset_assert_bulk(&reset_bulk);
modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
- clrsetbits_le32(pdata->phy_intf, modemask,
- modereg << pdata->reg_shift);
+ socfpga_secure_reg_update32((phys_addr_t)pdata->phy_intf, modemask,
+ modereg << pdata->reg_shift);
reset_release_bulk(&reset_bulk);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 07/20] arm: socfpga: Disable "spin-table" method for booting Linux
From: Chee Hong Ang Standard PSCI function "CPU_ON" provided by ATF is now used by Linux kernel to bring up the secondary CPUs to enable SMP booting in Linux on SoC 64bits platform. Signed-off-by: Chee Hong Ang --- arch/arm/mach-socfpga/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 969698c..6549033 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -33,7 +33,6 @@ config TARGET_SOCFPGA_AGILEX bool select ARMV8_MULTIENTRY select ARMV8_SET_SMPEN - select ARMV8_SPIN_TABLE select CLK select NCORE_CACHE select SPL_CLK if SPL @@ -77,7 +76,6 @@ config TARGET_SOCFPGA_STRATIX10 bool select ARMV8_MULTIENTRY select ARMV8_SET_SMPEN - select ARMV8_SPIN_TABLE select FPGA_STRATIX10 choice -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 12/20] arm: socfpga: Secure register access in PHY mode setup
From: Chee Hong Ang Allow access to System Manager's EMAC control register from non-secure mode during PHY mode setup. Signed-off-by: Chee Hong Ang --- arch/arm/mach-socfpga/misc_s10.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c index 2d63175..894753e 100644 --- a/arch/arm/mach-socfpga/misc_s10.c +++ b/arch/arm/mach-socfpga/misc_s10.c @@ -18,6 +18,7 @@ #include #include #include +#include #include @@ -65,9 +66,9 @@ static u32 socfpga_phymode_setup(u32 gmac_index, const char *phymode) else return -EINVAL; - clrsetbits_le32(socfpga_get_sysmgr_addr() + SYSMGR_SOC64_EMAC0 + - gmac_index, - SYSMGR_EMACGRP_CTRL_PHYSEL_MASK, modereg); + socfpga_secure_reg_update32(socfpga_get_sysmgr_addr() + + SYSMGR_SOC64_EMAC0 + gmac_index, + SYSMGR_EMACGRP_CTRL_PHYSEL_MASK, modereg); return 0; } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 13/20] arm: socfpga: Secure register access for reading PLL frequency
From: Chee Hong Ang
Allow reading external oscillator and FPGA clock's frequency from
System Manager's Boot Scratch Register 1 and Boot Scratch Register 2
in non-secure mode (EL2) on SoC 64bits platform.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/wrap_pll_config_s10.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-socfpga/wrap_pll_config_s10.c
b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
index 3da8579..7bd92d0 100644
--- a/arch/arm/mach-socfpga/wrap_pll_config_s10.c
+++ b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
const struct cm_config * const cm_get_default_config(void)
{
@@ -39,8 +40,8 @@ const unsigned int cm_get_osc_clk_hz(void)
writel(clock,
socfpga_get_sysmgr_addr() + SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
#endif
- return readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
+ return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
}
const unsigned int cm_get_intosc_clk_hz(void)
@@ -56,6 +57,6 @@ const unsigned int cm_get_fpga_clk_hz(void)
writel(clock,
socfpga_get_sysmgr_addr() + SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
#endif
- return readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
+ return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 10/20] arm: socfpga: Add secure register access helper functions for SoC 64bits
From: Chee Hong Ang
These secure register access functions allow U-Boot proper running
at EL2 (non-secure) to access System Manager's secure registers
by calling the ATF's PSCI runtime services (EL3/secure). If these
helper functions are called from secure mode (EL3), the helper
function will direct access the secure registers without calling
the ATF's PSCI runtime services.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/Makefile | 2 +
.../mach-socfpga/include/mach/secure_reg_helper.h | 20 +++
arch/arm/mach-socfpga/secure_reg_helper.c | 67 ++
3 files changed, 89 insertions(+)
create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 3310e92..4b46b65 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -34,6 +34,7 @@ obj-y += mailbox_s10.o
obj-y += misc_s10.o
obj-y += mmu-arm64_s10.o
obj-y += reset_manager_s10.o
+obj-y += secure_reg_helper.o
obj-y += system_manager_s10.o
obj-y += timer_s10.o
obj-y += wrap_pinmux_config_s10.o
@@ -47,6 +48,7 @@ obj-y += mailbox_s10.o
obj-y += misc_s10.o
obj-y += mmu-arm64_s10.o
obj-y += reset_manager_s10.o
+obj-y += secure_reg_helper.o
obj-y += system_manager_s10.o
obj-y += timer_s10.o
obj-y += wrap_pinmux_config_s10.o
diff --git a/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
new file mode 100644
index 000..0dc6534
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2019 Intel Corporation
+ *
+ */
+
+#ifndef_SECURE_REG_HELPER_H_
+#define_SECURE_REG_HELPER_H_
+
+#ifdef CONFIG_ARM_SMCCC
+u32 socfpga_secure_reg_read32(phys_addr_t reg_addr);
+void socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr);
+void socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val);
+#else
+#define socfpga_secure_reg_read32 readl
+#define socfpga_secure_reg_write32 writel
+#define socfpga_secure_reg_update32clrsetbits_le32
+#endif
+
+#endif /* _SECURE_REG_HELPER_H_ */
diff --git a/arch/arm/mach-socfpga/secure_reg_helper.c
b/arch/arm/mach-socfpga/secure_reg_helper.c
new file mode 100644
index 000..2968fab
--- /dev/null
+++ b/arch/arm/mach-socfpga/secure_reg_helper.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+u32 socfpga_secure_reg_read32(phys_addr_t reg_addr)
+{
+ int ret;
+ u64 ret_arg;
+ u64 args[1];
+
+ if (current_el() == 3)
+ return readl(reg_addr);
+
+ args[0] = (u64)reg_addr;
+ ret = invoke_smc(INTEL_SIP_SMC_REG_READ, args, 1, &ret_arg, 1);
+ if (ret) {
+ /* SMC call return error */
+ hang();
+ }
+
+ return ret_arg;
+}
+
+void socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr)
+{
+ int ret;
+ u64 args[2];
+
+ if (current_el() == 3) {
+ writel(val, (u32 *)reg_addr);
+ } else {
+ args[0] = (u64)reg_addr;
+ args[1] = val;
+ ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
+ if (ret) {
+ /* SMC call return error */
+ hang();
+ }
+ }
+}
+
+void socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val)
+{
+ int ret;
+ u64 args[3];
+
+ if (current_el() == 3) {
+ clrsetbits_le32(reg_addr, mask, val);
+ } else {
+ args[0] = (u64)reg_addr;
+ args[1] = mask;
+ args[2] = val;
+ ret = invoke_smc(INTEL_SIP_SMC_REG_UPDATE, args, 3, NULL, 0);
+ if (ret) {
+ /* SMC call return error */
+ hang();
+ }
+ }
+}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 14/20] mmc: dwmmc: socfpga: Secure register access in MMC driver
From: Chee Hong Ang
Allow MMC driver to access System Manager's SDMMC control
register in non-secure mode (EL2).
Signed-off-by: Chee Hong Ang
---
drivers/mmc/socfpga_dw_mmc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 568a3e7..b856a0b 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -56,10 +57,12 @@ static void socfpga_dwmci_clksel(struct dwmci_host *host)
debug("%s: drvsel %d smplsel %d\n", __func__,
priv->drvsel, priv->smplsel);
- writel(sdmmc_mask, socfpga_get_sysmgr_addr() + SYSMGR_SDMMC);
+ socfpga_secure_reg_write32(sdmmc_mask, socfpga_get_sysmgr_addr() +
+ SYSMGR_SDMMC);
debug("%s: SYSMGR_SDMMCGRP_CTRL_REG = 0x%x\n", __func__,
- readl(socfpga_get_sysmgr_addr() + SYSMGR_SDMMC));
+ socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+ SYSMGR_SDMMC));
/* Enable SDMMC clock */
setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 19/20] arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config status
From: Chee Hong Ang
Since SSBL is now running in non-secure mode (EL2), do_bridge_reset()
no longer send mailbox commands to SDM directly to query the status
of the FPGA configuration. Now, it invokes SMC service calls to ATF
(running at EL3) to perform the query.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/misc_s10.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 894753e..2bef4ec 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -154,10 +155,17 @@ void do_bridge_reset(int enable, unsigned int mask)
{
/* Check FPGA status before bridge enable */
if (enable) {
- int ret = mbox_get_fpga_config_status(MBOX_RECONFIG_STATUS);
+ u64 arg = 1;
- if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
- ret = mbox_get_fpga_config_status(MBOX_CONFIG_STATUS);
+ /* Send MBOX_RECONFIG_STATUS to SDM */
+ int ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+NULL, 0);
+
+ if (ret && ret != INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY) {
+ /* Send MBOX_CONFIG_STATUS to SDM */
+ ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE,
+&arg, 1, NULL, 0);
+ }
if (ret)
return;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 06/20] configs: socfpga: Enable FIT image loading with ATF support
From: Chee Hong Ang SPL now loads ATF (BL31), U-Boot proper and DTB from FIT image. The new boot flow with ATF support is as follow: SPL -> ATF (BL31) -> U-Boot proper -> OS (Linux) Signed-off-by: Chee Hong Ang --- configs/socfpga_agilex_defconfig| 8 +++- configs/socfpga_stratix10_defconfig | 8 +++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig index cdb9396..48c1bd6 100644 --- a/configs/socfpga_agilex_defconfig +++ b/configs/socfpga_agilex_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y -CONFIG_SYS_TEXT_BASE=0x1000 +CONFIG_SYS_TEXT_BASE=0x20 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_OFFSET=0x200 @@ -9,10 +9,16 @@ CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y CONFIG_IDENT_STRING="socfpga_agilex" CONFIG_SPL_FS_FAT=y CONFIG_SPL_TEXT_BASE=0xFFE0 +CONFIG_FIT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its" CONFIG_BOOTDELAY=5 +CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y CONFIG_SPL_CACHE=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x3c0 +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="SOCFPGA_AGILEX # " CONFIG_CMD_MEMTEST=y diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig index 903d17b..c3d6e68 100644 --- a/configs/socfpga_stratix10_defconfig +++ b/configs/socfpga_stratix10_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y -CONFIG_SYS_TEXT_BASE=0x1000 +CONFIG_SYS_TEXT_BASE=0x20 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_OFFSET=0x200 @@ -9,9 +9,15 @@ CONFIG_TARGET_SOCFPGA_STRATIX10_SOCDK=y CONFIG_IDENT_STRING="socfpga_stratix10" CONFIG_SPL_FS_FAT=y CONFIG_SPL_TEXT_BASE=0xFFE0 +CONFIG_FIT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its" CONFIG_BOOTDELAY=5 +CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x3C0 +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # " CONFIG_CMD_MEMTEST=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 08/20] arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
From: Chee Hong Ang
Allow U-Boot proper running in non-secure mode (EL2) to invoke
SMC call to ATF's PSCI runtime services such as System Manager's
registers access, 2nd phase bitstream FPGA reconfiguration,
Remote System Update (RSU) and etc.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/include/mach/misc.h | 3 +++
arch/arm/mach-socfpga/misc_s10.c | 26 ++
2 files changed, 29 insertions(+)
diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
b/arch/arm/mach-socfpga/include/mach/misc.h
index f6de1cc..b939250 100644
--- a/arch/arm/mach-socfpga/include/mach/misc.h
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -43,4 +43,7 @@ void do_bridge_reset(int enable, unsigned int mask);
void socfpga_pl310_clear(void);
void socfpga_get_managers_addr(void);
+#ifdef CONFIG_ARM_SMCCC
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len);
+#endif
#endif /* _SOCFPGA_MISC_H_ */
diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index a3f5b43..2d63175 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -164,3 +164,29 @@ void do_bridge_reset(int enable, unsigned int mask)
socfpga_bridges_reset(enable);
}
+
+#ifdef CONFIG_ARM_SMCCC
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len)
+{
+ int i;
+ struct pt_regs regs;
+
+ memset(®s, 0, sizeof(regs));
+
+ regs.regs[0] = func_id;
+
+ if (args) {
+ for (i = 0; i < arg_len; i++)
+ regs.regs[i + 1] = args[i];
+ }
+
+ smc_call(®s);
+
+ if (ret_arg) {
+ for (i = 0; i < ret_len; i++)
+ ret_arg[i] = regs.regs[i + 1];
+ }
+
+ return regs.regs[0];
+}
+#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 20/20] sysreset: socfpga: Invoke PSCI call for COLD reset
From: Chee Hong Ang
Instead of sending mailbox command to trigger COLD reset, sysreset driver
now call "SYSTEM_RESET" PSCI runtime service provided by ATF to trigger
COLD reset.
Signed-off-by: Chee Hong Ang
---
drivers/sysreset/sysreset_socfpga_s10.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/sysreset/sysreset_socfpga_s10.c
b/drivers/sysreset/sysreset_socfpga_s10.c
index 9837aad..96cf61e 100644
--- a/drivers/sysreset/sysreset_socfpga_s10.c
+++ b/drivers/sysreset/sysreset_socfpga_s10.c
@@ -8,13 +8,11 @@
#include
#include
#include
-#include
static int socfpga_sysreset_request(struct udevice *dev,
enum sysreset_t type)
{
- puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
- mbox_reset_cold();
+ psci_system_reset();
return -EINPROGRESS;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
+ Ye li
Hi Stefan,
> -Original Message-
> From: Stefan Roese
> Sent: Monday, December 2, 2019 3:38 PM
> To: Kuldeep Singh ; u-boot@lists.denx.de
> Cc: Priyanka Jain ; ja...@amarulasolutions.com;
> frieder.schre...@kontron.de
> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem
> framework
>
> Caution: EXT Email
>
> Hi Kuldeep,
>
> On 29.11.19 06:54, Kuldeep Singh wrote:
> > This entire patch series migrate freescale qspi driver to spi-mem
> framework.
> >
> > Patch 1 removes the old fsl qspi driver
> >
> > Patch 2 adds new qspi driver incorporating spi-mem framework which is
> > ported version of linux qspi driver. Initial port was done by Frieder.
> > Now, no more direct access to spi-nor memory is possible. Few changes
> > were introduced to prevent uboot crash such as to add complete flash
> > size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number
> > instead of 1k. Immediate effect was observed on pfe while using 1k
> > size as it access spi-nor memory directly. Using complete flash size
> resolves the crash but data read will not be valid.
> >
> > Patch 3 removes unused config options.
> >
> > Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header
> files.
> > SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR.
> >
> > Patch 5 removes unused num-cs property for imx platforms
> >
> > Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR
> is
> > no longer required and can be removed.
> >
> > Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files.
> > While enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR
> at the same time.
> >
> > Patch 8 updates the device-tree properties treewide for layerscape
> > boards by aligning it with linux device-tree properties.
>
> Many thanks for working on this. I've tested this patchset on a new i-
> MX6ULL/ULZ based board and noticed, that I still need to add this kind of
> patch to make it work on my platform:
>
> drivers/spi/fsl_qspi.c
> index
> 788fa0416f..0946f9d6d5 100644 @@ -44,6 +44,9 @@
> DECLARE_GLOBAL_DATA_PTR;
> #define QUADSPI_IPCR 0x08
> #define QUADSPI_IPCR_SEQID(x) ((x) << 24)
>
> +#define QUADSPI_FLSHCR 0x0c
> +#define QUADSPI_FLSHCR_TDH(x) ((x) << 16)
> +
> #define QUADSPI_BUF3CR0x1c
> #define QUADSPI_BUF3CR_ALLMST_MASKBIT(31)
> #define QUADSPI_BUF3CR_ADATSZ(x) ((x) << 8)
> @@ -666,6 +669,16 @@ static int fsl_qspi_default_setup(struct fsl_qspi *q)
> QUADSPI_BUF3CR_ADATSZ(q->devtype_data->ahb_buf_size / 8),
> base + QUADSPI_BUF3CR);
>
> + /*
> +* Clear THD bits to configure SDR mode instead of DDR mode. This
> +* might be necessary, as the BootROM in some versions and on some
> +* SoCs sets these bits to 0x1 for DDR mode. But this driver needs
> +* it set to SDR mode instead.
> +*/
> + reg = qspi_readl(q, base + QUADSPI_FLSHCR);
> + reg &= ~QUADSPI_FLSHCR_TDH(0x3);
> + qspi_writel(q, reg, base + QUADSPI_FLSHCR);
>
> This was suggested by Frieder and is also integrated in the Linux QSPI driver:
>
> Commit ID f6910679e17a ("spi: spi-fsl-qspi: Clear TDH bits in FLSHCR
> register")
>
> What is the status of SDR vs DDR mode in this driver? Is this driver version
> supposed to handle DDR mode correctly? If not, could you please integrate
> this patch (or Frieder's Linux patch) into your patchset so that the driver
> also
> works on i.MX6ULL/ULZ ?
I will port Frieder's patch for i.mx from Linux to Uboot.
Meanwhile, I am waiting for comments on other patches so that I'll incorporate
all changes in next version.
@Ye li
Please see attached email for reference.
Does Frieder's patch(f6910679e17a) resolves the fix proposed by you.
Also, can you please help in testing other i.mx platforms after including the
change.
Thanks
Kuldeep
>
> Thanks,
> Stefan
>
> > Frieder Schrempf (1):
> >imx: imx6sx: Remove unused 'num-cs' property
> >
> > Kuldeep Singh (7):
> >spi: Remove old freescale qspi driver
> >spi: Transform the FSL QuadSPI driver to use the SPI MEM API
> >treewide: Remove unused FSL QSPI config options
> >configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
> >configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig
> >configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
> >treewide: Update fsl qspi node dt properties as per spi-mem driver
> >
> > arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +-
> > arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +-
> > arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +-
> > arch/arm/dts/fsl-ls1012a.dtsi |4 +-
> > arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +-
> > arch/arm/dts/fsl-ls1043a.dtsi |6 +-
> > arch/arm/dts/fsl-ls1046a-frwy.dts
[U-Boot] [PATCH] configs: ls1028aqds: enable mdio muxing by default
LS1028A QDS boards have a MDIO MUX and they require the driver for it for PHYs to work. Signed-off-by: Alex Marginean --- configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 2 ++ configs/ls1028aqds_tfa_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index 65e467817e..b5dceb4471 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -50,9 +50,11 @@ CONFIG_PHY_ATHEROS=y CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_DM_MDIO=y +CONFIG_DM_MDIO_MUX=y CONFIG_DM_DSA=y CONFIG_E1000=y CONFIG_MSCC_FELIX_SWITCH=y +CONFIG_MDIO_MUX_I2CREG=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_DM_PCI_COMPAT=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 40d259d907..e75d140e94 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -56,9 +56,11 @@ CONFIG_PHY_ATHEROS=y CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_DM_MDIO=y +CONFIG_DM_MDIO_MUX=y CONFIG_DM_DSA=y CONFIG_E1000=y CONFIG_MSCC_FELIX_SWITCH=y +CONFIG_MDIO_MUX_I2CREG=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_DM_PCI_COMPAT=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/6] fat: write: adjust data written in each partial write
The code for handing file overwrite incorrectly calculated the amount of
data to write when writing to the last non-cluster aligned chunk. Fix
this by ensuring that no more data than the 'filesize' is written to disk.
While touching min()-based calculations, change it to type-safe min_t()
function.
Signed-off-by: Marek Szyprowski
---
This patch finally fixes the issue revealed by the test script from the
previous patch. The correctness of the change has been also verified by
the following additional test scripts:
--->8-fat_test2.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 7936 >/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8-fat_test3.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 8448 >/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8-fat_test4.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 2304 >/tmp/model/file0007.raw
yes GHI | head -c 2304 >>/tmp/model/file0007.raw
yes DEF | head -c 2304 >>/tmp/model/file0007.raw
yes GHI | head -c 2304 >>/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8---
Feel free to prepare a proper sandbox/py_test based tests based on
the provided test scripts.
---
fs/fat/fat_write.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index f946030f7d..8e4a235d7c 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -813,7 +813,9 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
pos, __u8 *buffer,
offset = 0;
else
offset = pos - cur_pos;
- wsize = min(cur_pos + actsize, filesize) - pos;
+ wsize = min_t(unsigned long long, actsize, filesize - cur_pos);
+ wsize -= offset;
+
if (get_set_cluster(mydata, curclust, offset,
buffer, wsize, &actsize)) {
printf("Error get-and-setting cluster\n");
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/6] Raspberry Pi4: add support for DFU over USB
Hi All!
This patchset enables support for DFU over USB protocol on Raspberry Pi4
board. The board has DWC2 UDC controller connected to the USB-C power
connector. Enabling DFU on it, make the u-boot development much more
convenient, as one no longer needs to swap SD-card between RPi4 board and
host machine to update the u-boot binary.
Patches are based on current 'master' u-boot branch. They were tested on
the 2019-07-10-raspbian-buster-lite.img sd-card image with the following
lines added to config.txt:
dtoverlay=dwc2,dr_mode=peripheral
dtparam=i2c_arm=on
dtparam=spi=on
enable_uart=1
uart_2ndstage=1
kernel=u-boot.bin
To enable DFU, one has to enter follwing command:
# dfu 0 mmc 0
During the development of this feature I've encountered a serious bugs
in FAT write code. Over-writing discontiguous files always caused serious
filesystem corruption. This was especially anoying, because the system
environment is kept on FAT volume in uboot.env file, so 'saveenv'
basically corrupted the boot partiting on the second call. Another bunch
of the issues in the FAT write code has been revealed while removing
predefined file size limit in DFU MMC code and then running sandbox
tests.
I hope that my fixes for FAT code will be helpful for non-RPi users too.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v4:
- rechecked the FAT related fixes, it turned out that much simpler patch
fixes both issues discovered while working on DFU support; added simple
sandbox based tests reveleaing the issue and showing correctness
of the fix
- rebased patches onto current u-boot's master branch: 4b19b89ca4a8
("Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot";)
v3: https://patchwork.ozlabs.org/cover/1200793/
- fixed one more FAT issue revealed by sandbox tests
v3: (patch 6/6 posted separately): https://patchwork.ozlabs.org/patch/1195645/
- fixed non-RPi4 builds (missing #else ENV_DFU_SETTINGS def)
- removed config.txt entity (not needed in uboot-based boot)
- switched arm64 kernel filename to 'Image'
v2: https://patchwork.ozlabs.org/cover/1166589/
- added changes to rpi_4_defconfig too (arm64 version)
- extended DFU entity list by confix.txt, cmdline.txt and Image.gz
- fixed missing '\0' at the end of dfu_alt_info env
- added reviewed-by tags
- added patches for DFU MMC to remove file size limit
- added patch for fat write to fix issues on non-zero file offset
(revealed by previous patch)
v1: https://patchwork.ozlabs.org/cover/1162770/
- initial version
Patch summary:
Marek Szyprowski (6):
fat: write: fix broken write to fragmented files
fat: write: adjust data written in each partial write
dfu: mmc: rearrange the code
dfu: mmc: remove file size limit for io operations
usb: dwc2_udc_otg: add bcm2835 SoC (Raspberry Pi4) support
config: enable DFU over USB on Raspberry Pi4 boards
configs/rpi_4_32b_defconfig| 11 +++
configs/rpi_4_defconfig| 11 +++
drivers/dfu/dfu_mmc.c | 93 +-
drivers/usb/gadget/dwc2_udc_otg.c | 2 +
drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 12 +--
fs/fat/fat_write.c | 8 +-
include/configs/rpi.h | 20 +
7 files changed, 112 insertions(+), 45 deletions(-)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/6] usb: dwc2_udc_otg: add bcm2835 SoC (Raspberry Pi4) support
Broadcom 2835 SoC requires special conversion of physical memory addresses
for DMA purpose, so add needed wrappers to dwc2_udc_otg driver. Also extend
the list of compatible devices with 'brcm,bcm2835-usb' entry. This allows
to use USB gadget drivers (i.e. DFU) on Raspberry Pi4 boards.
Signed-off-by: Marek Szyprowski
Reviewed-by: Lukasz Majewski
---
drivers/usb/gadget/dwc2_udc_otg.c | 2 ++
drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 12 ++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
b/drivers/usb/gadget/dwc2_udc_otg.c
index 35f4147840..49f342eb21 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1213,6 +1214,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev)
static const struct udevice_id dwc2_udc_otg_ids[] = {
{ .compatible = "snps,dwc2" },
+ { .compatible = "brcm,bcm2835-usb" },
{ .compatible = "st,stm32mp1-hsotg",
.data = (ulong)dwc2_set_stm32mp1_hsotg_params },
{},
diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index 7eb632d3b1..5e695b4ff2 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -28,7 +28,7 @@ static inline void dwc2_udc_ep0_zlp(struct dwc2_udc *dev)
{
u32 ep_ctrl;
- writel(usb_ctrl_dma_addr, ®->in_endp[EP0_CON].diepdma);
+ writel(phys_to_bus((unsigned long)usb_ctrl_dma_addr),
®->in_endp[EP0_CON].diepdma);
writel(DIEPT_SIZ_PKT_CNT(1), ®->in_endp[EP0_CON].dieptsiz);
ep_ctrl = readl(®->in_endp[EP0_CON].diepctl);
@@ -49,7 +49,7 @@ static void dwc2_udc_pre_setup(void)
writel(DOEPT_SIZ_PKT_CNT(1) | sizeof(struct usb_ctrlrequest),
®->out_endp[EP0_CON].doeptsiz);
- writel(usb_ctrl_dma_addr, ®->out_endp[EP0_CON].doepdma);
+ writel(phys_to_bus((unsigned long)usb_ctrl_dma_addr),
®->out_endp[EP0_CON].doepdma);
ep_ctrl = readl(®->out_endp[EP0_CON].doepctl);
writel(ep_ctrl|DEPCTL_EPENA, ®->out_endp[EP0_CON].doepctl);
@@ -75,7 +75,7 @@ static inline void dwc2_ep0_complete_out(void)
writel(DOEPT_SIZ_PKT_CNT(1) | sizeof(struct usb_ctrlrequest),
®->out_endp[EP0_CON].doeptsiz);
- writel(usb_ctrl_dma_addr, ®->out_endp[EP0_CON].doepdma);
+ writel(phys_to_bus((unsigned long)usb_ctrl_dma_addr),
®->out_endp[EP0_CON].doepdma);
ep_ctrl = readl(®->out_endp[EP0_CON].doepctl);
writel(ep_ctrl|DEPCTL_EPENA|DEPCTL_CNAK,
@@ -113,7 +113,7 @@ static int setdma_rx(struct dwc2_ep *ep, struct
dwc2_request *req)
(unsigned long) ep->dma_buf +
ROUND(ep->len, CONFIG_SYS_CACHELINE_SIZE));
- writel((unsigned long) ep->dma_buf, ®->out_endp[ep_num].doepdma);
+ writel(phys_to_bus((unsigned long)ep->dma_buf),
®->out_endp[ep_num].doepdma);
writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
®->out_endp[ep_num].doeptsiz);
writel(DEPCTL_EPENA|DEPCTL_CNAK|ctrl, ®->out_endp[ep_num].doepctl);
@@ -161,7 +161,7 @@ static int setdma_tx(struct dwc2_ep *ep, struct
dwc2_request *req)
while (readl(®->grstctl) & TX_FIFO_FLUSH)
;
- writel((unsigned long) ep->dma_buf, ®->in_endp[ep_num].diepdma);
+ writel(phys_to_bus((unsigned long)ep->dma_buf),
®->in_endp[ep_num].diepdma);
writel(DIEPT_SIZ_PKT_CNT(pktcnt) | DIEPT_SIZ_XFER_SIZE(length),
®->in_endp[ep_num].dieptsiz);
@@ -921,7 +921,7 @@ static int dwc2_udc_get_status(struct dwc2_udc *dev,
(unsigned long) usb_ctrl +
ROUND(sizeof(g_status), CONFIG_SYS_CACHELINE_SIZE));
- writel(usb_ctrl_dma_addr, ®->in_endp[EP0_CON].diepdma);
+ writel(phys_to_bus(usb_ctrl_dma_addr), ®->in_endp[EP0_CON].diepdma);
writel(DIEPT_SIZ_PKT_CNT(1) | DIEPT_SIZ_XFER_SIZE(2),
®->in_endp[EP0_CON].dieptsiz);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/6] dfu: mmc: remove file size limit for io operations
Add support for operations on files larger than
CONFIG_SYS_DFU_MAX_FILE_SIZE. The buffered io mechanism is still used for
aggregating io requests, so for files up to CONFIG_SYS_DFU_MAX_FILE_SIZE
nothing is changed and they will be handled in a single filesystem call.
Signed-off-by: Marek Szyprowski
Acked-by: Lukasz Majewski
---
drivers/dfu/dfu_mmc.c | 46 ---
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index e52c02be10..0d495a785b 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -17,7 +17,7 @@
static unsigned char *dfu_file_buf;
static u64 dfu_file_buf_len;
-static long dfu_file_buf_filled;
+static u64 dfu_file_buf_offset;
static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
@@ -123,7 +123,7 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity
*dfu,
switch (op) {
case DFU_OP_READ:
- ret = fs_read(dfu->name, (size_t)buf, offset, 0, &size);
+ ret = fs_read(dfu->name, (size_t)buf, offset, *len, &size);
if (ret) {
puts("dfu: fs_read error!\n");
return ret;
@@ -154,25 +154,38 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity
*dfu,
static int mmc_file_buf_write(struct dfu_entity *dfu, u64 offset, void *buf,
long *len)
{
- if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE) {
+ int ret = 0;
+
+ if (offset == 0) {
dfu_file_buf_len = 0;
- return -EINVAL;
+ dfu_file_buf_offset = 0;
}
/* Add to the current buffer. */
+ if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE)
+ *len = CONFIG_SYS_DFU_MAX_FILE_SIZE - dfu_file_buf_len;
memcpy(dfu_file_buf + dfu_file_buf_len, buf, *len);
dfu_file_buf_len += *len;
- return 0;
+ if (dfu_file_buf_len == CONFIG_SYS_DFU_MAX_FILE_SIZE) {
+ ret = mmc_file_op(DFU_OP_WRITE, dfu, dfu_file_buf_offset,
+ dfu_file_buf, &dfu_file_buf_len);
+ dfu_file_buf_offset += dfu_file_buf_len;
+ dfu_file_buf_len = 0;
+ }
+
+ return ret;
}
static int mmc_file_buf_write_finish(struct dfu_entity *dfu)
{
- int ret = mmc_file_op(DFU_OP_WRITE, dfu, 0, dfu_file_buf,
- &dfu_file_buf_len);
+ int ret = mmc_file_op(DFU_OP_WRITE, dfu, dfu_file_buf_offset,
+ dfu_file_buf, &dfu_file_buf_len);
/* Now that we're done */
dfu_file_buf_len = 0;
+ dfu_file_buf_offset = 0;
+
return ret;
}
@@ -219,12 +232,9 @@ int dfu_get_medium_size_mmc(struct dfu_entity *dfu, u64
*size)
return 0;
case DFU_FS_FAT:
case DFU_FS_EXT4:
- dfu_file_buf_filled = -1;
ret = mmc_file_op(DFU_OP_SIZE, dfu, 0, NULL, size);
if (ret < 0)
return ret;
- if (*size > CONFIG_SYS_DFU_MAX_FILE_SIZE)
- return -1;
return 0;
default:
printf("%s: Layout (%s) not (yet) supported!\n", __func__,
@@ -238,19 +248,23 @@ static int mmc_file_buf_read(struct dfu_entity *dfu, u64
offset, void *buf,
long *len)
{
int ret;
- u64 file_len;
- if (dfu_file_buf_filled == -1) {
- ret = mmc_file_op(DFU_OP_READ, dfu, 0, dfu_file_buf, &file_len);
+ if (offset == 0 || offset >= dfu_file_buf_offset + dfu_file_buf_len ||
+ offset + *len < dfu_file_buf_offset) {
+ u64 file_len = CONFIG_SYS_DFU_MAX_FILE_SIZE;
+
+ ret = mmc_file_op(DFU_OP_READ, dfu, offset, dfu_file_buf,
+ &file_len);
if (ret < 0)
return ret;
- dfu_file_buf_filled = file_len;
+ dfu_file_buf_len = file_len;
+ dfu_file_buf_offset = offset;
}
- if (offset + *len > dfu_file_buf_filled)
+ if (offset + *len > dfu_file_buf_offset + dfu_file_buf_len)
return -EINVAL;
/* Add to the current buffer. */
- memcpy(buf, dfu_file_buf + offset, *len);
+ memcpy(buf, dfu_file_buf + offset - dfu_file_buf_offset, *len);
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/6] fat: write: fix broken write to fragmented files
The code for handing file overwrite incorrectly assumed that the file on
disk is always contiguous. This resulted in corrupting disk structure
every time when write to existing fragmented file happened. Fix this
by adding proper check for cluster discontinuity and adjust chunk size
on each partial write.
Signed-off-by: Marek Szyprowski
---
This patch partially fixes the issue revealed by the following test
script:
--->8-fat_test1.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 16384 >/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8---
Overwritting a discontiguous test file (file0007.raw) no longer causes
corruption to file0003.raw, which's data lies between the chunks of the
test file. The amount of data written to disk is still incorrect, what
causes damage to the file (file0005.raw), which's data lies next to the
test file. This will be fixed by the next patch.
Feel free to prepare a proper sandbox/py_test based tests based on the
provided test scripts.
---
fs/fat/fat_write.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 729cf39630..f946030f7d 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -794,6 +794,8 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
pos, __u8 *buffer,
newclust = get_fatent(mydata, endclust);
+ if (newclust != endclust + 1)
+ break;
if (IS_LAST_CLUST(newclust, mydata->fatsize))
break;
if (CHECK_CLUST(newclust, mydata->fatsize)) {
@@ -824,8 +826,6 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
pos, __u8 *buffer,
if (filesize <= cur_pos)
break;
- /* CHECK: newclust = get_fatent(mydata, endclust); */
-
if (IS_LAST_CLUST(newclust, mydata->fatsize))
/* no more clusters */
break;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 6/6] config: enable DFU over USB on Raspberry Pi4 boards
Enable support for DFU over USB. This requires to enable USB gadget, DWC2 UDC OTG driver and DFU command. DFU entities are defined for the following firmware objects: u-boot.bin, uboot.env, config.txt, and zImage/Image. Signed-off-by: Marek Szyprowski Reviewed-by: Lukasz Majewski --- configs/rpi_4_32b_defconfig | 11 +++ configs/rpi_4_defconfig | 11 +++ include/configs/rpi.h | 20 3 files changed, 42 insertions(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 7ff390cd24..9d0515029c 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_SYS_PROMPT="U-Boot> " +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y @@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_DFU_MMC=y CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y @@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set # CONFIG_REQUIRE_SERIAL_CONSOLE is not set +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_CONSOLE_SCROLL_LINES=10 diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index c5089eb9c8..3d660d182a 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_SYS_PROMPT="U-Boot> " +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y @@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_DFU_MMC=y CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y @@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set # CONFIG_REQUIRE_SERIAL_CONSOLE is not set +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_CONSOLE_SCROLL_LINES=10 diff --git a/include/configs/rpi.h b/include/configs/rpi.h index 83e258a6b9..b53a4b65d0 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -74,6 +74,25 @@ #define CONFIG_TFTP_TSIZE #endif +/* DFU over USB/UDC */ +#ifdef CONFIG_CMD_DFU +#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_1M +#define CONFIG_SYS_DFU_MAX_FILE_SIZE SZ_2M + +#ifdef CONFIG_ARM64 +#define KERNEL_FILENAME"Image" +#else +#define KERNEL_FILENAME"zImage" +#endif + +#define ENV_DFU_SETTINGS \ + "dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;" \ + "config.txt fat 0 1;" \ + KERNEL_FILENAME " fat 0 1\0" +#else +#define ENV_DFU_SETTINGS "" +#endif + /* Console configuration */ #define CONFIG_SYS_CBSIZE 1024 @@ -188,6 +207,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ ENV_DEVICE_SETTINGS \ + ENV_DFU_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ BOOTENV -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/6] dfu: mmc: rearrange the code
Rename functions for bufferred file io operations to make them easier to
understand. Also add missing file offset argument to them (currently
unused). All this is a preparation to remove predefined file size limit
(CONFIG_SYS_DFU_MAX_FILE_SIZE) for DFU read/write operations.
Signed-off-by: Marek Szyprowski
Acked-by: Lukasz Majewski
---
drivers/dfu/dfu_mmc.c | 61 ---
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 5b551f6ae1..e52c02be10 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -91,22 +91,8 @@ static int mmc_block_op(enum dfu_op op, struct dfu_entity
*dfu,
return 0;
}
-static int mmc_file_buffer(struct dfu_entity *dfu, void *buf, long *len)
-{
- if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE) {
- dfu_file_buf_len = 0;
- return -EINVAL;
- }
-
- /* Add to the current buffer. */
- memcpy(dfu_file_buf + dfu_file_buf_len, buf, *len);
- dfu_file_buf_len += *len;
-
- return 0;
-}
-
static int mmc_file_op(enum dfu_op op, struct dfu_entity *dfu,
- void *buf, u64 *len)
+ u64 offset, void *buf, u64 *len)
{
char dev_part_str[8];
int ret;
@@ -137,7 +123,7 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity
*dfu,
switch (op) {
case DFU_OP_READ:
- ret = fs_read(dfu->name, (size_t)buf, 0, 0, &size);
+ ret = fs_read(dfu->name, (size_t)buf, offset, 0, &size);
if (ret) {
puts("dfu: fs_read error!\n");
return ret;
@@ -145,7 +131,7 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity
*dfu,
*len = size;
break;
case DFU_OP_WRITE:
- ret = fs_write(dfu->name, (size_t)buf, 0, *len, &size);
+ ret = fs_write(dfu->name, (size_t)buf, offset, *len, &size);
if (ret) {
puts("dfu: fs_write error!\n");
return ret;
@@ -166,6 +152,30 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity
*dfu,
return ret;
}
+static int mmc_file_buf_write(struct dfu_entity *dfu, u64 offset, void *buf,
long *len)
+{
+ if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE) {
+ dfu_file_buf_len = 0;
+ return -EINVAL;
+ }
+
+ /* Add to the current buffer. */
+ memcpy(dfu_file_buf + dfu_file_buf_len, buf, *len);
+ dfu_file_buf_len += *len;
+
+ return 0;
+}
+
+static int mmc_file_buf_write_finish(struct dfu_entity *dfu)
+{
+ int ret = mmc_file_op(DFU_OP_WRITE, dfu, 0, dfu_file_buf,
+ &dfu_file_buf_len);
+
+ /* Now that we're done */
+ dfu_file_buf_len = 0;
+ return ret;
+}
+
int dfu_write_medium_mmc(struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
@@ -177,7 +187,7 @@ int dfu_write_medium_mmc(struct dfu_entity *dfu,
break;
case DFU_FS_FAT:
case DFU_FS_EXT4:
- ret = mmc_file_buffer(dfu, buf, len);
+ ret = mmc_file_buf_write(dfu, offset, buf, len);
break;
default:
printf("%s: Layout (%s) not (yet) supported!\n", __func__,
@@ -193,11 +203,7 @@ int dfu_flush_medium_mmc(struct dfu_entity *dfu)
if (dfu->layout != DFU_RAW_ADDR) {
/* Do stuff here. */
- ret = mmc_file_op(DFU_OP_WRITE, dfu, dfu_file_buf,
- &dfu_file_buf_len);
-
- /* Now that we're done */
- dfu_file_buf_len = 0;
+ ret = mmc_file_buf_write_finish(dfu);
}
return ret;
@@ -214,7 +220,7 @@ int dfu_get_medium_size_mmc(struct dfu_entity *dfu, u64
*size)
case DFU_FS_FAT:
case DFU_FS_EXT4:
dfu_file_buf_filled = -1;
- ret = mmc_file_op(DFU_OP_SIZE, dfu, NULL, size);
+ ret = mmc_file_op(DFU_OP_SIZE, dfu, 0, NULL, size);
if (ret < 0)
return ret;
if (*size > CONFIG_SYS_DFU_MAX_FILE_SIZE)
@@ -227,14 +233,15 @@ int dfu_get_medium_size_mmc(struct dfu_entity *dfu, u64
*size)
}
}
-static int mmc_file_unbuffer(struct dfu_entity *dfu, u64 offset, void *buf,
+
+static int mmc_file_buf_read(struct dfu_entity *dfu, u64 offset, void *buf,
long *len)
{
int ret;
u64 file_len;
if (dfu_file_buf_filled == -1) {
- ret = mmc_file_op(DFU_OP_READ, dfu, dfu_file_buf, &file_len);
+ ret = mmc_file_op(DFU_OP_READ, dfu, 0, dfu_file_buf, &file_len);
if (ret < 0)
return ret;
dfu_file_buf_filled = file_len;
@@ -259,7 +266,7 @@ int dfu_read_medium_mmc(struct dfu_entit
Re: [U-Boot] [PATCH RESEND v2 02/10] dma: ti: k3-udma: Query DMA channels allocated from Resource Manager
On 02/12/2019 10:54, Vignesh Raghavendra wrote:
On K3 SoCs, DMA channels are shared across multiple entities, therefore
U-Boot DMA driver needs to query resource range from centralised
resource management controller i.e SystemFirmware and use DMA channels
allocated for A72 host. Add support for the same.
Signed-off-by: Vignesh Raghavendra
---
v2:
Address comments on v1 from Grygorii
Squash patch 5 (of v1) into this patch
drivers/dma/ti/k3-udma-hwdef.h | 19 +++
drivers/dma/ti/k3-udma.c | 274 +++--
2 files changed, 214 insertions(+), 79 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-hwdef.h b/drivers/dma/ti/k3-udma-hwdef.h
index c88399a815ea..228a44cb73cf 100644
--- a/drivers/dma/ti/k3-udma-hwdef.h
+++ b/drivers/dma/ti/k3-udma-hwdef.h
@@ -181,4 +181,23 @@
#define PDMA_STATIC_TR_Z(x) \
(((x) << PDMA_STATIC_TR_Z_SHIFT) & PDMA_STATIC_TR_Z_MASK)
+enum udma_rm_range {
+ RM_RANGE_TCHAN = 0,
+ RM_RANGE_RCHAN,
+ RM_RANGE_RFLOW,
+ RM_RANGE_LAST,
+};
+
+struct udma_tisci_rm {
+ const struct ti_sci_handle *tisci;
+ const struct ti_sci_rm_udmap_ops *tisci_udmap_ops;
+ u32 tisci_dev_id;
+
+ /* tisci information for PSI-L thread pairing/unpairing */
+ const struct ti_sci_rm_psil_ops *tisci_psil_ops;
+ u32 tisci_navss_dev_id;
+
+ struct ti_sci_resource *rm_ranges[RM_RANGE_LAST];
+};
I'd move it in k3-udma.c
+
#endif /* K3_NAVSS_UDMA_HWDEF_H_ */
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index a5fc7809bc41..2f82ab0955a4 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -11,12 +11,14 @@
#include
[...]
--
Best regards,
grygorii
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND v2 00/10] dma: ti: k3-udma: Add support for J721e
On 02/12/2019 10:54, Vignesh Raghavendra wrote: This series adds DMA support for J721e using exist K3 UDMA driver. One main change is thati, on J721e, DMA resources such as DMA channels are shared between different entities running on different cores of the SoC. Therefore, U-Boot running on A72 core should request range of resources allocated to it from centralized resource management core (DMSC) and use only the allocated resource. First two patches adds support for dynamically querying and using allocated resources. Remaining patches fix issues when using UDMA driver on a 32 bit core like R5. Last patch adds a new compatible for J721e Vignesh Raghavendra (10): lib: Import few bitmap functions from Linux dma: ti: k3-udma: Query DMA channels allocated from Resource Manager soc: ti: k3-navss-ringacc: Flush/invalidate caches on ring push/pop soc: ti: k3-navss-ringacc: Get SYSFW reference from DT phandle dma: ti: k3-udma: Remove coherency check for cache ops dma: ti: k3-udma: Fix debug prints during enabling MEM_TO_DEV transfers dma: ti: k3-udma: Switch to exposed ring mode dma: ti: k3-udma: Fix ring push operation for 32 bit cores dma: ti: k3-udma: Fix build warnings when building for 32 bit platforms dma: ti: k3-udma: Add new compatible to J721e drivers/dma/ti/k3-udma-hwdef.h| 19 ++ drivers/dma/ti/k3-udma.c | 346 -- drivers/soc/ti/k3-navss-ringacc.c | 13 +- include/linux/bitmap.h| 133 include/linux/bitops.h| 12 ++ 5 files changed, 403 insertions(+), 120 deletions(-) minor comment to patch 2. Otherwise: Reviewed-by: Grygorii Strashko -- Best regards, grygorii ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: eth-uclass: ignore unavailable devices
On 12/1/2019 5:43 PM, Michael Walle wrote:
Am 2019-12-01 01:55, schrieb Alexandru Marginean:
Hi Michael,
On 10/22/2019 1:03 AM, Michael Walle wrote:
device_probe() may fail in which case the seq_id will be -1. Don't
display these devices during startup. While this is only a cosmetic
change, the return value of eth_initialize() will also change to the
actual number of available devices. The return value is only used in
spl_net to decide whether there are any devices to boot from. So
returning only available devices is also more correct in that case.
Signed-off-by: Michael Walle
---
net/eth-uclass.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 3bd98b01ad..acd59216e3 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -420,20 +420,25 @@ int eth_initialize(void)
bootstage_mark(BOOTSTAGE_ID_NET_ETH_INIT);
do {
- if (num_devices)
- printf(", ");
+ if (dev->seq != -1) {
+ if (num_devices)
+ printf(", ");
- printf("eth%d: %s", dev->seq, dev->name);
+ printf("eth%d: %s", dev->seq, dev->name);
- if (ethprime && dev == prime_dev)
- printf(" [PRIME]");
+ if (ethprime && dev == prime_dev)
+ printf(" [PRIME]");
+ }
eth_write_hwaddr(dev);
+ if (dev->seq != -1)
+ num_devices++;
uclass_next_device_check(&dev);
- num_devices++;
} while (dev);
+ if (!num_devices)
+ printf("No ethernet found.\n");
putc('\n');
}
What would you say about something like this instead? It's a bit more
compact and should be functionally equivalent:
sure, but I've noticed that this is only part of the fix (or isn't even
necessary). At least, it doesn't work if the first device is unavailable,
because eth_get_dev() will then fail. You should be able to reproduce
the issue if you disable the first enetc of the LS1028A. Then network
should only work if ethact is set.
I've traced that back to the pci enumeration which doesn't respect the
'status = "disabled"' property. But instead someone added that check to
the enetc driver, but that doesn't really work, because the device is
already included in the uclass list. See separate patch, I'll send in a
minute.
-michael
For disabled nodes the pci_find_and_bind_driver patch is sufficient.
We should probably deal with drivers failing to probe for other reasons
too, there could be other legitimate reasons for that to happen.
how about the eth_initialize patch plus:
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -69,8 +69,8 @@ struct udevice *eth_get_dev(void)
uc_priv = eth_get_uclass_priv();
if (!uc_priv->current)
- eth_errno = uclass_first_device(UCLASS_ETH,
- &uc_priv->current);
+ uclass_get_device_by_seq(UCLASS_ETH, 0, &uc_priv->current);
+
return uc_priv->current;
}
Since seq == -1 on devices that fail to probe this code will ignore them.
Or add uclass helpers that only deal with devices that probe
successfully: uclass_get_first_device_active,
uclass_get_next_device_active and uclass_foreach_dev_active.
Alex
net/eth-uclass.c | 54 ++--
1 file changed, 25 insertions(+), 29 deletions(-)
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 1bc8947749..4d4eaeb371 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -390,10 +390,16 @@ int eth_rx(void)
int eth_initialize(void)
{
+ struct udevice *dev, *prime_dev = NULL;
+ char *ethprime = env_get("ethprime");
int num_devices = 0;
- struct udevice *dev;
+ struct uclass *uc;
eth_common_init();
+ eth_set_dev(NULL);
+
+ if (ethprime)
+ prime_dev = eth_get_dev_by_name(ethprime);
/*
* Devices need to write the hwaddr even if not started so that
Linux
@@ -401,40 +407,30 @@ int eth_initialize(void)
* This is accomplished by attempting to probe each device and
calling
* their write_hwaddr() operation.
*/
- uclass_first_device_check(UCLASS_ETH, &dev);
- if (!dev) {
- printf("No ethernet found.\n");
- bootstage_error(BOOTSTAGE_ID_NET_ETH_START);
- } else {
- char *ethprime = env_get("ethprime");
- struct udevice *prime_dev = NULL;
+ uclass_get(UCLASS_ETH, &uc);
+ uclass_foreach_dev(dev, uc) {
+ if (device_probe(dev))
+ continue;
+
+ eth_write_hwaddr(dev);
+
+ if (num_devices)
+ printf(", ");
+ printf("eth%d: %s", dev->seq, dev->name);
- if (ethprime)
- prime_dev = eth_get_dev_by_name(ethprime);
- if (prime_dev) {
+ if (dev == prime_dev) {
eth_set_dev(prime_dev);
eth_current_changed();
-
Re: [U-Boot] [PATCH v2 3/6] net: ti: am65-cpsw-nuss: Rework RX flow ID handling
On 02/12/2019 10:59, Vignesh Raghavendra wrote:
Get flow ID information for RX DMA channel using dma_get_cfg() interface
instead of reading from DT. This is required in order to avoid DT update
whenever there is change in the range of flow ID allocated to the host.
Signed-off-by: Vignesh Raghavendra
Acked-by: Joe Hershberger
---
drivers/net/ti/am65-cpsw-nuss.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 06b06639506a..2e14f4be862f 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -99,7 +99,6 @@ struct am65_cpsw_common {
u32 port_num;
struct am65_cpsw_port ports[AM65_CPSW_CPSWNU_MAX_PORTS];
- u32 rflow_id_base;
struct mii_dev *bus;
u32 bus_freq;
@@ -276,6 +275,7 @@ static int am65_cpsw_start(struct udevice *dev)
struct am65_cpsw_common *common = priv->cpsw_common;
struct am65_cpsw_port *port = &common->ports[priv->port_id];
struct am65_cpsw_port *port0 = &common->ports[0];
+ struct ti_udma_drv_chan_cfg_data *dma_rx_cfg_data;
int ret, i;
ret = power_domain_on(&common->pwrdmn);
@@ -341,7 +341,8 @@ static int am65_cpsw_start(struct udevice *dev)
writel(PKTSIZE_ALIGN, port0->port_base + AM65_CPSW_PN_RX_MAXLEN_REG);
/* set base flow_id */
- writel(common->rflow_id_base,
+ dma_get_cfg(&common->dma_rx, 0, (void **)&dma_rx_cfg_data);
+ writel(dma_rx_cfg_data->flow_id_base,
port0->port_base + AM65_CPSW_P0_FLOW_ID_REG);
Could you add dbg print here, hence you've dropped it below, pls?
/* Reset and enable the ALE */
@@ -669,11 +670,6 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
AM65_CPSW_CPSW_NU_ALE_BASE;
cpsw_common->mdio_base = cpsw_common->ss_base + AM65_CPSW_MDIO_BASE;
- cpsw_common->rflow_id_base = 0;
- cpsw_common->rflow_id_base =
- dev_read_u32_default(dev, "ti,rx-flow-id-base",
-cpsw_common->rflow_id_base);
-
ports_np = dev_read_subnode(dev, "ports");
if (!ofnode_valid(ports_np)) {
ret = -ENOENT;
@@ -761,12 +757,11 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
if (ret)
goto out;
- dev_info(dev, "K3 CPSW: nuss_ver: 0x%08X cpsw_ver: 0x%08X ale_ver: 0x%08X Ports:%u rflow_id_base:%u mdio_freq:%u\n",
+ dev_info(dev, "K3 CPSW: nuss_ver: 0x%08X cpsw_ver: 0x%08X ale_ver: 0x%08X
Ports:%u mdio_freq:%u\n",
readl(cpsw_common->ss_base),
readl(cpsw_common->cpsw_base),
readl(cpsw_common->ale_base),
cpsw_common->port_num,
-cpsw_common->rflow_id_base,
cpsw_common->bus_freq);
out:
--
Best regards,
grygorii
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] arm: dts: k3-j721e-common-proc-board: Add DMA and CPSW related DT nodes
On 02/12/2019 10:59, Vignesh Raghavendra wrote:
Add DT nodes related to DMA and CPSW to -u-boot.dtsi to get networking
up on J721e EVM.
Signed-off-by: Vignesh Raghavendra
Acked-by: Joe Hershberger
---
.../k3-j721e-common-proc-board-u-boot.dtsi| 239 ++
1 file changed, 239 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 541da22c4889..f3857b9100bb 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -3,11 +3,18 @@
* Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
*/
+#include
+#include
+
/ {
chosen {
stdout-path = "serial2:115200n8";
tick-timer = &timer1;
};
+
+ aliases {
+ ethernet0 = &cpsw_port1;
+ };
};
&cbass_main{
@@ -24,6 +31,184 @@
clock-frequency = <2500>;
u-boot,dm-spl;
};
+
[...]
+&davinci_mdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ /* TODO: phy reset:
TCA9555RTWR(i2c:0x21)[p04].GPIO_MCU_RGMII_RSTN */
Could you drop this TODO pls?
+ ti,rx-internal-delay = ;
+ ti,fifo-depth = ;
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&phy0>;
+};
+
+&mcu_cpsw {
+ reg = <0x0 0x4600 0x0 0x20>,
+ <0x0 0x40f00200 0x0 0x2>;
+ reg-names = "cpsw_nuss", "mac_efuse";
+
+ cpsw-phy-sel@40f04040 {
+ compatible = "ti,am654-cpsw-phy-sel";
+ reg= <0x0 0x40f04040 0x0 0x4>;
+ reg-names = "gmii-sel";
+ };
+};
--
Best regards,
grygorii
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] J721e: Add networking support
On 02/12/2019 10:59, Vignesh Raghavendra wrote: This patch enables networking support for TI's J721e SoC. Patch 1 adds a new interface to DMA uclass to get channel specific private/configuration data. Patch 2 to 4 use this interface to pass data from J721e's UDMA driver to CPSW ethernet driver. Last two patches add DMA and CPSW DT nodes and configs. Depends on [1] for ethernet to work [1] http://patchwork.ozlabs.org/project/uboot/list/?series=145954 v2: Address comments from Grygorii. Collect Acks Few minor comments. Reviewed-by: Grygorii Strashko Vignesh Raghavendra (6): dma: Introduce dma_get_cfg() interface dma: ti: k3-udma: Implement dma_get_cfg() interface net: ti: am65-cpsw-nuss: Rework RX flow ID handling net: ti: am65-cpsw-nuss: Add new compatible for J721e arm: dts: k3-j721e-common-proc-board: Add DMA and CPSW related DT nodes configs: j721e_evm_a72_defconfig: Enable DMA and Ethernet .../k3-j721e-common-proc-board-u-boot.dtsi| 239 ++ configs/j721e_evm_a72_defconfig | 8 + drivers/dma/dma-uclass.c | 12 + drivers/dma/ti/k3-udma.c | 30 ++- drivers/net/ti/am65-cpsw-nuss.c | 14 +- include/dma-uclass.h | 11 + include/dma.h | 11 + include/linux/soc/ti/ti-udma.h| 19 ++ 8 files changed, 334 insertions(+), 10 deletions(-) -- Best regards, grygorii ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] omapl138_lcdk: fix MMC boot
On Mon, Dec 2, 2019 at 3:32 AM Bartosz Golaszewski wrote: > > czw., 14 lis 2019 o 16:10 Bartosz Golaszewski napisał(a): > > > > From: Bartosz Golaszewski > > > > Booting from MMC on omapl138-lcdk is currently broken after we enabled > > driver-model in SPL. While I know what's wrong - the bind() callback not > > being called - I can't for the life of me figure out how to fix it. > > > > I'm still working on proper changes, but for now, I'd like to propose > > this series which fixes MMC boot with a workaround in which we call > > mmc_boot() manually from probe. > > > > First two patches drop some legacy code that's no longer needed. The > > third patch adds a U_BOOT_DEVICE() for mmc as we don't yet have full > > DT support (also in-progress). The last patch adds the workaround to > > the davinci mmc driver. > > > > This series depends on Adam Ford's patch increasing the pre-reloc > > malloc pool. > > > > [1] https://patchwork.ozlabs.org/patch/1192574/ > > > > Bartosz Golaszewski (4): > > mmc: davinci: drop support for ti,dm6441-mmc > > mmc: davinci: drop struct davinci_mmc_plat > > board: omapl138_lcdk: add the mmc device to SPL > > mmc: davinci: fix mmc boot in SPL > > > > arch/arm/mach-davinci/Kconfig | 1 + > > .../mach-davinci/include/mach/sdmmc_defs.h| 6 -- > > board/davinci/da8xxevm/omapl138_lcdk.c| 10 ++- > > drivers/mmc/davinci_mmc.c | 73 +++ > > 4 files changed, 36 insertions(+), 54 deletions(-) > > > > -- > > 2.23.0 > > > > Gentle ping. I wonder if having a 'fixes:' tag would help move things along. adam > > Bart ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
+ Ashish Hi Kuldeep, On 29.11.19 06:54, Kuldeep Singh wrote: > This entire patch series migrate freescale qspi driver to spi-mem framework. First, thanks for working on this. I have this on my list for quite a long time, but struggled to find enough time to actually get it done. > > Patch 1 removes the old fsl qspi driver You shouldn't remove the old driver before the new one is in place, as this breaks the build in between the two patches. > > Patch 2 adds new qspi driver incorporating spi-mem framework which is ported > version of linux qspi driver. Initial port was done by Frieder. Now, no more > direct access to spi-nor memory is possible. Few changes were introduced to > prevent uboot crash such as to add complete flash size to SFA1AD, SFA2AD, > SFB1AD, SFB2AD based on chip select number instead of 1k. Immediate effect was > observed on pfe while using 1k size as it access spi-nor memory directly. > Using > complete flash size resolves the crash but data read will not be valid. Can you provide more information about the problem/crash you experience and the platform you are working on? Are you referring to the same issue as Ashish in this discussion here [1]? There are two reasons why I'd like to avoid using the whole memory mapped area for AHB access. First, I'd like to keep the U-Boot driver as close as possible to the Linux driver. Second, the intention of the spi-mem layer is to abstract the flash layer and therefore this driver should work independently of flash type or size. With your version this wouldn't be the case if you connect a flash that is bigger than the memory map for example. Thanks, Frieder [1]: https://lists.denx.de/pipermail/u-boot/2019-October/387788.html > > Patch 3 removes unused config options. > > Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header > files. > SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR. > > Patch 5 removes unused num-cs property for imx platforms > > Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR is no > longer > required and can be removed. > > Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files. While > enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR at the same > time. > > Patch 8 updates the device-tree properties treewide for layerscape boards by > aligning it with linux device-tree properties. > > Frieder Schrempf (1): >imx: imx6sx: Remove unused 'num-cs' property > > Kuldeep Singh (7): >spi: Remove old freescale qspi driver >spi: Transform the FSL QuadSPI driver to use the SPI MEM API >treewide: Remove unused FSL QSPI config options >configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig >configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig >configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig >treewide: Update fsl qspi node dt properties as per spi-mem driver > > arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +- > arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +- > arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +- > arch/arm/dts/fsl-ls1012a.dtsi |4 +- > arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +- > arch/arm/dts/fsl-ls1043a.dtsi |6 +- > arch/arm/dts/fsl-ls1046a-frwy.dts |5 +- > arch/arm/dts/fsl-ls1046a-qds.dtsi |5 +- > arch/arm/dts/fsl-ls1046a-rdb.dts |5 +- > arch/arm/dts/fsl-ls1046a.dtsi |4 +- > arch/arm/dts/fsl-ls1088a-qds.dts |5 +- > arch/arm/dts/fsl-ls1088a-rdb.dts |5 +- > arch/arm/dts/fsl-ls1088a.dtsi |2 +- > arch/arm/dts/fsl-ls2080a-qds.dts |5 +- > arch/arm/dts/fsl-ls2080a.dtsi |4 +- > arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |5 +- > arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi |2 - > arch/arm/dts/imx6sx-sdb-u-boot.dtsi |2 - > arch/arm/dts/ls1021a-twr.dtsi |5 +- > arch/arm/dts/ls1021a.dtsi |6 +- > .../include/asm/arch-fsl-layerscape/config.h |1 - > arch/arm/include/asm/arch-ls102xa/config.h|1 - > configs/ls1012aqds_qspi_defconfig |2 +- > configs/ls1012aqds_tfa_defconfig |2 +- > configs/ls1012ardb_qspi_SECURE_BOOT_defconfig |2 +- > configs/ls1012ardb_qspi_defconfig |2 +- > configs/ls1012ardb_tfa_defconfig |2 +- > configs/ls1043aqds_qspi_defconfig |2 +- > configs/ls1043aqds_sdcard_qspi_defconfig |2 +- > configs/ls1043aqds_tfa_SECURE_BOOT_defconfig |2 + > configs/ls1043aqds_tfa_defconfig |2 +- > configs/ls1046aqds_qspi_defconfig |2 +- > configs/ls1046aqds_sdcard_qspi_defconfig |2 +- > configs/ls1046aqds_tfa_SECURE_BOOT_defconfig |1 + > configs/ls1046aqds_tfa_defconfig
Re: [U-Boot] [PATCH v2 1/6] net: introduce DSA class for Ethernet switches
On 12/1/2019 5:17 AM, Florian Fainelli wrote: On 11/30/2019 6:21 PM, Alexandru Marginean wrote: Hi Joe, On 11/30/2019 1:56 AM, Joe Hershberger wrote: Hi Alex, On Mon, Nov 25, 2019 at 9:54 AM Alex Marginean wrote: DSA stands for Distributed Switch Architecture and it covers switches that are connected to the CPU through an Ethernet link and generally use frame tags to pass information about the source/destination ports to/from CPU. Front panel ports are presented as regular ethernet devices in U-Boot and they are expected to support the typical networking commands. DSA switches may be cascaded, DSA class code does not currently support this. Is it expected to eventually retrofit the other switch drivers that we have in U-Boot to use this? For now I would like to at least make sure that the uclass code allows that to happen. Longer term yes, it would be nice to get existing drivers converted. This is applicable to switches that rely on a master Eth device for I/O. The list should include switches that use DSA in kernel, of course: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa Some of these are under PHYs in U-Boot right now (like b53, mv88exxx), hooked up to the master Eth. This works, but comes with limitations, like this in b53 driver: * The configuration determines which PHY ports to activate using the * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on. Having these drivers converted should come with some benefits: - their DT nodes would be in sync with the kernel DSA bindings, - users would have some run-time control over the switch ports used for I/O, - driving PHYs of front panel ports comes more naturally with these ports being registered as eth devices. There are other switches which don't fall under DSA, those that present some sort of direct I/O interface to the CPU and don't rely on a master Eth device. These switched may not follow DSA bindings, since they are not technically DSA. For them we could either have a more generic Eth switch class or just let the drivers register the switch device or the ports on the switch as Eth devices. The Device Tree binding for DSA is actually fairly generic within the 'ports' container node, if you omit the ethernet phandle, this still allows you to describe a multi-port Ethernet switch with the data path being contained solely within the switch node and not spread across a DSA master and a discrete switch. At least, this could be a starting point. It is, I don't disagree with that. My argument is DSA-like binding isn't enforced in kernel tree for non-DSA switches (is it?) and allowing U-Boot to use existing kernel DTs for non-DSA switches is a good thing. Binding aside I still think DSA should be a class of its own in U-Boot. There are differences in the API between DSA ports and Eth devices and DSA uclass has the code dealing with master Eth, which is useless for non-DSA. I think this way the code and the interface to the drivers is simpler and more clear. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
On Mon, Dec 2, 2019 at 11:25 AM wrote: > > From: "Ang, Chee Hong" > > New U-boot flow with ARM Trusted Firmware (ATF) support: > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) Adding support for ATF means that using U-Boot on Stratix10 and Agilex without ATF keeps working, right? > > SPL loads the u-boot.itb which consist of: > 1) u-boot-nodtb.bin (U-Boot Proper image) > 2) u-boot.dtb (U-Boot Proper DTB) > 3) bl31.bin (ATF-BL31 image) > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager > register accesses and mailbox communications with Secure Device Manager > (SDM). > > Steps to build the U-Boot with ATF support: > 1) Build U-Boot > 2) Build ATF BL31 > 3) Copy ATF BL31 binary image into U-Boot's root folder > 4) "make u-boot.itb" to generate u-boot.itb > > These patchsets have dependency on: > [U-Boot,v8,00/19] Add Intel Agilex SoC support: > https://patchwork.ozlabs.org/cover/1201373/ > > Chee Hong Ang (19): > arm: socfpga: add fit source file for pack itb with ATF > arm: socfpga: Add function for checking description from FIT image > arm: socfpga: Load FIT image with ATF support > arm: socfpga: Override 'lowlevel_init' to support ATF > configs: socfpga: Enable FIT image loading with ATF support > arm: socfpga: Disable "spin-table" method for booting Linux > arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) > arm: socfpga: Define SMC function identifiers for PSCI SiP services > arm: socfpga: Add secure register access helper functions for SoC > 64bits > arm: socfpga: Secure register access for clock manager (SoC 64bits) > arm: socfpga: Secure register access in PHY mode setup > arm: socfpga: Secure register access for reading PLL frequency > mmc: dwmmc: socfpga: Secure register access in MMC driver > net: designware: socfpga: Secure register access in MAC driver > arm: socfpga: Secure register access in Reset Manager driver > arm: socfpga: stratix10: Initialize timer in SPL > arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF > arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config > status > sysreset: socfpga: Invoke PSCI call for COLD reset > > Dalon Westergreen (1): > configs: stratix10: Remove CONFIG_OF_EMBED This one is included in another series already: https://patchwork.ozlabs.org/user/todo/uboot/?series=132976 Does this mean that one will be abandonen? So the combined hex output part of that series is not required any more? Regards, Simon > > arch/arm/mach-socfpga/Kconfig | 2 - > arch/arm/mach-socfpga/Makefile | 4 + > arch/arm/mach-socfpga/board.c | 10 + > arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- > arch/arm/mach-socfpga/clock_manager_s10.c | 5 +- > arch/arm/mach-socfpga/include/mach/misc.h | 3 + > .../mach-socfpga/include/mach/secure_reg_helper.h | 20 ++ > arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ > arch/arm/mach-socfpga/misc_s10.c | 47 ++- > arch/arm/mach-socfpga/reset_manager_s10.c | 31 +- > arch/arm/mach-socfpga/secure_reg_helper.c | 67 > arch/arm/mach-socfpga/timer_s10.c | 3 +- > arch/arm/mach-socfpga/wrap_pll_config_s10.c| 9 +- > board/altera/soc64/its/fit_spl_atf.its | 51 +++ > configs/socfpga_agilex_defconfig | 8 +- > configs/socfpga_stratix10_defconfig| 9 +- > drivers/fpga/stratix10.c | 261 -- > drivers/mmc/socfpga_dw_mmc.c | 7 +- > drivers/net/dwmac_socfpga.c| 5 +- > drivers/sysreset/sysreset_socfpga_s10.c| 4 +- > include/configs/socfpga_soc64_common.h | 2 +- > include/linux/intel-smc.h | 374 > + > 22 files changed, 732 insertions(+), 243 deletions(-) > create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h > create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S > create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c > create mode 100644 board/altera/soc64/its/fit_spl_atf.its > create mode 100644 include/linux/intel-smc.h > > -- > 2.7.4 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > From: "Ang, Chee Hong" > > > > New U-boot flow with ARM Trusted Firmware (ATF) support: > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) > > Adding support for ATF means that using U-Boot on Stratix10 and Agilex without > ATF keeps working, right? ATF is needed in order for Stratix10 and Agilex's U-Boot to work. > > > > SPL loads the u-boot.itb which consist of: > > 1) u-boot-nodtb.bin (U-Boot Proper image) > > 2) u-boot.dtb (U-Boot Proper DTB) > > 3) bl31.bin (ATF-BL31 image) > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes > > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager > > register accesses and mailbox communications with Secure Device > > Manager (SDM). > > > > Steps to build the U-Boot with ATF support: > > 1) Build U-Boot > > 2) Build ATF BL31 > > 3) Copy ATF BL31 binary image into U-Boot's root folder > > 4) "make u-boot.itb" to generate u-boot.itb > > > > These patchsets have dependency on: > > [U-Boot,v8,00/19] Add Intel Agilex SoC support: > > https://patchwork.ozlabs.org/cover/1201373/ > > > > Chee Hong Ang (19): > > arm: socfpga: add fit source file for pack itb with ATF > > arm: socfpga: Add function for checking description from FIT image > > arm: socfpga: Load FIT image with ATF support > > arm: socfpga: Override 'lowlevel_init' to support ATF > > configs: socfpga: Enable FIT image loading with ATF support > > arm: socfpga: Disable "spin-table" method for booting Linux > > arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) > > arm: socfpga: Define SMC function identifiers for PSCI SiP services > > arm: socfpga: Add secure register access helper functions for SoC > > 64bits > > arm: socfpga: Secure register access for clock manager (SoC 64bits) > > arm: socfpga: Secure register access in PHY mode setup > > arm: socfpga: Secure register access for reading PLL frequency > > mmc: dwmmc: socfpga: Secure register access in MMC driver > > net: designware: socfpga: Secure register access in MAC driver > > arm: socfpga: Secure register access in Reset Manager driver > > arm: socfpga: stratix10: Initialize timer in SPL > > arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF > > arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config > > status > > sysreset: socfpga: Invoke PSCI call for COLD reset > > > > Dalon Westergreen (1): > > configs: stratix10: Remove CONFIG_OF_EMBED > > This one is included in another series already: > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976 > > Does this mean that one will be abandonen? > So the combined hex output part of that series is not required any more? > > Regards, > Simon > > > > > arch/arm/mach-socfpga/Kconfig | 2 - > > arch/arm/mach-socfpga/Makefile | 4 + > > arch/arm/mach-socfpga/board.c | 10 + > > arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- > > arch/arm/mach-socfpga/clock_manager_s10.c | 5 +- > > arch/arm/mach-socfpga/include/mach/misc.h | 3 + > > .../mach-socfpga/include/mach/secure_reg_helper.h | 20 ++ > > arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ > > arch/arm/mach-socfpga/misc_s10.c | 47 ++- > > arch/arm/mach-socfpga/reset_manager_s10.c | 31 +- > > arch/arm/mach-socfpga/secure_reg_helper.c | 67 > > arch/arm/mach-socfpga/timer_s10.c | 3 +- > > arch/arm/mach-socfpga/wrap_pll_config_s10.c| 9 +- > > board/altera/soc64/its/fit_spl_atf.its | 51 +++ > > configs/socfpga_agilex_defconfig | 8 +- > > configs/socfpga_stratix10_defconfig| 9 +- > > drivers/fpga/stratix10.c | 261 -- > > drivers/mmc/socfpga_dw_mmc.c | 7 +- > > drivers/net/dwmac_socfpga.c| 5 +- > > drivers/sysreset/sysreset_socfpga_s10.c| 4 +- > > include/configs/socfpga_soc64_common.h | 2 +- > > include/linux/intel-smc.h | 374 > > + > > 22 files changed, 732 insertions(+), 243 deletions(-) create mode > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h > > create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S > > create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c > > create mode 100644 board/altera/soc64/its/fit_spl_atf.its > > create mode 100644 include/linux/intel-smc.h > > > > -- > > 2.7.4 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/imximage: fix reported DCD information for MX7ULP
Hi Jorge,
Adding Breno.
On Thu, Nov 28, 2019 at 7:33 AM Jorge Ramirez-Ortiz wrote:
>
> On the MX7ULP, OCRAM for DCD is at 0x2f01
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> tools/imximage.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/tools/imximage.c b/tools/imximage.c
> index d7c0b6e883..762a06d468 100644
> --- a/tools/imximage.c
> +++ b/tools/imximage.c
> @@ -11,6 +11,7 @@
> #include "imagetool.h"
> #include
> #include "imximage.h"
> +#include
>
> #define UNDEFINED 0x
>
> @@ -524,8 +525,13 @@ static void print_hdr_v2(struct imx_header *imx_hdr)
> printf("HAB Blocks: 0x%08x 0x%08x 0x%08x\n",
>(uint32_t)fhdr_v2->self, 0,
>(uint32_t)(fhdr_v2->csf - fhdr_v2->self));
> +#ifndef CONFIG_MX7ULP
> printf("DCD Blocks: 0x0091 0x%08x 0x%08x\n",
>offs, be16_to_cpu(dcdlen));
> +#else
> + printf("DCD Blocks: 0x2f01 0x%08x 0x%08x\n",
> + offs, be16_to_cpu(dcdlen));
> +#endif
Can we make the DCD OCRAM a variable passed via Kconfig and selected
by SoC type?
This way we don't need to keep changing this for future SoCs.
What do you think?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong wrote: > > > On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > > > From: "Ang, Chee Hong" > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support: > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) > > > > Adding support for ATF means that using U-Boot on Stratix10 and Agilex > > without > > ATF keeps working, right? > ATF is needed in order for Stratix10 and Agilex's U-Boot to work. Is there a technical requirement for that? Regard, Simon > > > > > > SPL loads the u-boot.itb which consist of: > > > 1) u-boot-nodtb.bin (U-Boot Proper image) > > > 2) u-boot.dtb (U-Boot Proper DTB) > > > 3) bl31.bin (ATF-BL31 image) > > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) > > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes > > > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager > > > register accesses and mailbox communications with Secure Device > > > Manager (SDM). > > > > > > Steps to build the U-Boot with ATF support: > > > 1) Build U-Boot > > > 2) Build ATF BL31 > > > 3) Copy ATF BL31 binary image into U-Boot's root folder > > > 4) "make u-boot.itb" to generate u-boot.itb > > > > > > These patchsets have dependency on: > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support: > > > https://patchwork.ozlabs.org/cover/1201373/ > > > > > > Chee Hong Ang (19): > > > arm: socfpga: add fit source file for pack itb with ATF > > > arm: socfpga: Add function for checking description from FIT image > > > arm: socfpga: Load FIT image with ATF support > > > arm: socfpga: Override 'lowlevel_init' to support ATF > > > configs: socfpga: Enable FIT image loading with ATF support > > > arm: socfpga: Disable "spin-table" method for booting Linux > > > arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) > > > arm: socfpga: Define SMC function identifiers for PSCI SiP services > > > arm: socfpga: Add secure register access helper functions for SoC > > > 64bits > > > arm: socfpga: Secure register access for clock manager (SoC 64bits) > > > arm: socfpga: Secure register access in PHY mode setup > > > arm: socfpga: Secure register access for reading PLL frequency > > > mmc: dwmmc: socfpga: Secure register access in MMC driver > > > net: designware: socfpga: Secure register access in MAC driver > > > arm: socfpga: Secure register access in Reset Manager driver > > > arm: socfpga: stratix10: Initialize timer in SPL > > > arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF > > > arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config > > > status > > > sysreset: socfpga: Invoke PSCI call for COLD reset > > > > > > Dalon Westergreen (1): > > > configs: stratix10: Remove CONFIG_OF_EMBED > > > > This one is included in another series already: > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976 > > > > Does this mean that one will be abandonen? > > So the combined hex output part of that series is not required any more? > > > > Regards, > > Simon > > > > > > > > arch/arm/mach-socfpga/Kconfig | 2 - > > > arch/arm/mach-socfpga/Makefile | 4 + > > > arch/arm/mach-socfpga/board.c | 10 + > > > arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- > > > arch/arm/mach-socfpga/clock_manager_s10.c | 5 +- > > > arch/arm/mach-socfpga/include/mach/misc.h | 3 + > > > .../mach-socfpga/include/mach/secure_reg_helper.h | 20 ++ > > > arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ > > > arch/arm/mach-socfpga/misc_s10.c | 47 ++- > > > arch/arm/mach-socfpga/reset_manager_s10.c | 31 +- > > > arch/arm/mach-socfpga/secure_reg_helper.c | 67 > > > arch/arm/mach-socfpga/timer_s10.c | 3 +- > > > arch/arm/mach-socfpga/wrap_pll_config_s10.c| 9 +- > > > board/altera/soc64/its/fit_spl_atf.its | 51 +++ > > > configs/socfpga_agilex_defconfig | 8 +- > > > configs/socfpga_stratix10_defconfig| 9 +- > > > drivers/fpga/stratix10.c | 261 -- > > > drivers/mmc/socfpga_dw_mmc.c | 7 +- > > > drivers/net/dwmac_socfpga.c| 5 +- > > > drivers/sysreset/sysreset_socfpga_s10.c| 4 +- > > > include/configs/socfpga_soc64_common.h | 2 +- > > > include/linux/intel-smc.h | 374 > > > + > > > 22 files changed, 732 insertions(+), 243 deletions(-) create mode > > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h > > > create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S > > > create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c > > > create mode 100644 board/altera/soc64/its/fit_spl_atf.its > > > create mode
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > wrote: > > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support: > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) > > > > > > Adding support for ATF means that using U-Boot on Stratix10 and > > > Agilex without ATF keeps working, right? > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work. > > Is there a technical requirement for that? Yes. We are using ATF to provide PSCI services such as system reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as mailbox communications with Secure Device Manager and accessing the System Manager registers which are secure. Without PSCI services, we are able to boot until U-Boot proper only. Currently, our U-Boot in mainline doesn't boot to Linux due to these missing PSCI services. Another reason is we have another boot flow which is using ATF + UEFI. So now we are re-using the PSCI services from ATF so that now U-Boot and UEFI share the same ATF-BL31 image so that we don't have to reimplement another sets of PSCI services for U-Boot again. This will greatly reduce our engineering efforts. > > Regard, > Simon > > > > > > > > > SPL loads the u-boot.itb which consist of: > > > > 1) u-boot-nodtb.bin (U-Boot Proper image) > > > > 2) u-boot.dtb (U-Boot Proper DTB) > > > > 3) bl31.bin (ATF-BL31 image) > > > > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) > > > > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes > > > > SMC/PSCI calls provided by ATF to perform COLD reset, System > > > > Manager register accesses and mailbox communications with Secure > > > > Device Manager (SDM). > > > > > > > > Steps to build the U-Boot with ATF support: > > > > 1) Build U-Boot > > > > 2) Build ATF BL31 > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder > > > > 4) "make u-boot.itb" to generate u-boot.itb > > > > > > > > These patchsets have dependency on: > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support: > > > > https://patchwork.ozlabs.org/cover/1201373/ > > > > > > > > Chee Hong Ang (19): > > > > arm: socfpga: add fit source file for pack itb with ATF > > > > arm: socfpga: Add function for checking description from FIT image > > > > arm: socfpga: Load FIT image with ATF support > > > > arm: socfpga: Override 'lowlevel_init' to support ATF > > > > configs: socfpga: Enable FIT image loading with ATF support > > > > arm: socfpga: Disable "spin-table" method for booting Linux > > > > arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) > > > > arm: socfpga: Define SMC function identifiers for PSCI SiP services > > > > arm: socfpga: Add secure register access helper functions for SoC > > > > 64bits > > > > arm: socfpga: Secure register access for clock manager (SoC 64bits) > > > > arm: socfpga: Secure register access in PHY mode setup > > > > arm: socfpga: Secure register access for reading PLL frequency > > > > mmc: dwmmc: socfpga: Secure register access in MMC driver > > > > net: designware: socfpga: Secure register access in MAC driver > > > > arm: socfpga: Secure register access in Reset Manager driver > > > > arm: socfpga: stratix10: Initialize timer in SPL > > > > arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF > > > > arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config > > > > status > > > > sysreset: socfpga: Invoke PSCI call for COLD reset > > > > > > > > Dalon Westergreen (1): > > > > configs: stratix10: Remove CONFIG_OF_EMBED > > > > > > This one is included in another series already: > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976 > > > > > > Does this mean that one will be abandonen? > > > So the combined hex output part of that series is not required any more? > > > > > > Regards, > > > Simon > > > > > > > > > > > arch/arm/mach-socfpga/Kconfig | 2 - > > > > arch/arm/mach-socfpga/Makefile | 4 + > > > > arch/arm/mach-socfpga/board.c | 10 + > > > > arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- > > > > arch/arm/mach-socfpga/clock_manager_s10.c | 5 +- > > > > arch/arm/mach-socfpga/include/mach/misc.h | 3 + > > > > .../mach-socfpga/include/mach/secure_reg_helper.h | 20 ++ > > > > arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ > > > > arch/arm/mach-socfpga/misc_s10.c | 47 ++- > > > > arch/arm/mach-socfpga/reset_manager_s10.c | 31 +- > > > > arch/arm/mach-socfpga/secure_reg_helper.c | 67 > > > > arch/arm/mach-socfpga/timer_s10.c | 3 +- > > > > arch/arm/mach-socfpga/wrap_pll_config_s10.c| 9 +- > > > > board/altera/soc64/its/fit_spl_atf.its | 51 +++ > > >
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > wrote: > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support: > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux > > > > > (EL1) > > > > > > > > Adding support for ATF means that using U-Boot on Stratix10 and > > > > Agilex without ATF keeps working, right? > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work. > > > > Is there a technical requirement for that? > Yes. We are using ATF to provide PSCI services such as system reset (COLD > reset), > CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as > mailbox communications with Secure Device Manager and accessing the System > Manager registers which are secure. > Without PSCI services, we are able to boot until U-Boot proper only. > Currently, > our U-Boot in mainline doesn't boot to Linux due to these missing PSCI > services. > Another reason is we have another boot flow which is using ATF + UEFI. So now > we are re-using the PSCI services from ATF so that now U-Boot and UEFI share > the same ATF-BL31 image so that we don't have to reimplement another sets of > PSCI services for U-Boot again. > This will greatly reduce our engineering efforts. > > > > Regard, > > Simon > > > > > > > > > > > > SPL loads the u-boot.itb which consist of: > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image) > > > > > 2) u-boot.dtb (U-Boot Proper DTB) > > > > > 3) bl31.bin (ATF-BL31 image) > > > > > > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) > > > > > > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it > > > > > invokes SMC/PSCI calls provided by ATF to perform COLD reset, > > > > > System Manager register accesses and mailbox communications with > > > > > Secure Device Manager (SDM). > > > > > > > > > > Steps to build the U-Boot with ATF support: > > > > > 1) Build U-Boot > > > > > 2) Build ATF BL31 > > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder > > > > > 4) "make u-boot.itb" to generate u-boot.itb > > > > > > > > > > These patchsets have dependency on: > > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support: > > > > > https://patchwork.ozlabs.org/cover/1201373/ > > > > > > > > > > Chee Hong Ang (19): > > > > > arm: socfpga: add fit source file for pack itb with ATF > > > > > arm: socfpga: Add function for checking description from FIT image > > > > > arm: socfpga: Load FIT image with ATF support > > > > > arm: socfpga: Override 'lowlevel_init' to support ATF > > > > > configs: socfpga: Enable FIT image loading with ATF support > > > > > arm: socfpga: Disable "spin-table" method for booting Linux > > > > > arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) > > > > > arm: socfpga: Define SMC function identifiers for PSCI SiP services > > > > > arm: socfpga: Add secure register access helper functions for SoC > > > > > 64bits > > > > > arm: socfpga: Secure register access for clock manager (SoC 64bits) > > > > > arm: socfpga: Secure register access in PHY mode setup > > > > > arm: socfpga: Secure register access for reading PLL frequency > > > > > mmc: dwmmc: socfpga: Secure register access in MMC driver > > > > > net: designware: socfpga: Secure register access in MAC driver > > > > > arm: socfpga: Secure register access in Reset Manager driver > > > > > arm: socfpga: stratix10: Initialize timer in SPL > > > > > arm: socfpga: stratix10: Refactor FPGA reconfig driver to support > > > > > ATF > > > > > arm: socfpga: Bridge reset now invokes SMC calls to query FPGA > > > > > config > > > > > status > > > > > sysreset: socfpga: Invoke PSCI call for COLD reset > > > > > > > > > > Dalon Westergreen (1): > > > > > configs: stratix10: Remove CONFIG_OF_EMBED > > > > > > > > This one is included in another series already: > > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976 > > > > > > > > Does this mean that one will be abandonen? > > > > So the combined hex output part of that series is not required any more? Sorry, I missed this part. Thanks for reminding the patches from Dalon. These patchsets needed Dalon's previous patches to work. Especially the patch to remove "CONFIG_OF_EMBED" from the defconfig file. I didn't know whether these patches will get accepted to mainline or not. If you are basically OK with those patches from Dalon. I will remove Dalon's patch from my patchsets when submitting the next patchsets. > > > > > > > > Regards, > > > > Simon > > > > > > > > > > > > > > arch/arm/mach-socfpga/Kconfig | 2 - > > > > > arch/arm/mach-socfpga/Makefile | 4 + > > > > > arch/arm/mach-socfpga/board.c | 10 + > > > > > arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- > > > > > arch/arm/mach-socfpga/clock_manager_s10.c
Re: [U-Boot] Load Debian/Fedora via EFI
On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
> On 11/29/19 11:16 AM, Michal Simek wrote:
>> Hi,
>>
>> I tried to boot latest debian and fedora rootfs via distro boot and
>> getting errors.
>> I have tried to run just one command and it is failing.
>>
>> ZynqMP> bootefi bootmgr ${fdtcontroladdr}
>> BootOrder not defined
>> EFI boot manager: Cannot load any image
>>
>> How to define BootOrder?
>>
>> Thanks,
>> Michal
>
> # Booting via boot manager
>
> U-Boot currently has no runtime support for variables. But Linaro is
> working on it. So update-grub cannot set the variables for you.
Who from Linaro is working on it? Akashi?
>
> You can use the efidebug command to prepare for booting via the boot
> manager:
>
> => efidebug boot add 0001 Debian mmc 0:1 \
> efi/debian/grubarm.efi console=${console}
>
> There seems to be a bug with communication lines in U-Boot. So you
> actually have to put this into a single line.
>
> => efidebug boot order 0001
>
> Use saveenv if you want to save the settings.
>
> If you do not want to use the internal device tree load the proper
> device tree, e.g.
>
> => load mmc 0:2 $fdt_addr_r dtb
>
> Now you are ready to boot via the boot manager:
>
> => bootefi bootmgr $fdt_addr_r
>
> # Booting via distro defaults
>
> DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the
> UEFI binary from efi/boot/bootaa64.efi on ARM64. See
> ./include/config_distro_bootcmd.h.
>
> OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does
> not.
Fedora is the same case.
I got it working based on your guidance but would be IMHO better to
extend distroboot to cover one of the major distribution even through
workaround till variable support is done.
>
> # Booting via boot script.
>
> On Debian I use package flash-kernel to keep /boot/dtb in sync with the
> kernel and have a u-boot.scr.uimg script with something like the
> following lines:
>
> setenv bootargs console=${console}
> load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi
> load mmc 2:2 ${fdt_addr_r} dtb
> bootefi ${kernel_addr_r} ${fdt_addr_r}
flash-kernel is interesting. It generates u-boot script but if extX
partition has no bootable flag u-boot distroboot ignores it completely.
What's your default partition setup?
>
> Alternatively you could use package flash-kernel and implement the
> /etc/flash-kernel/preboot.d/
> hook to start GRUB, cf.
> /etc/flash-kernel/bootscript/bootscr.uboot-generic
>
> I currently have no Fedora system in use.
>
you can take a look.
https://alt.fedoraproject.org/alt/
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 100/101] x86: apl: Add FSP support
Hi Simon,
On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
>
> The memory and silicon init parts of the FSP need support code to work.
> Add this for Apollo Lake.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v5:
> - Allocate the FSP-S data instead of using the stack
> - Rename APOLLOLAKE_USB2_PORT_MAX
>
> Changes in v4:
> - Adjust the comment for struct dw_i2c_speed_config
> - Rename arch_fsp_s_preinit() to arch_fsps_preinit()
> - Switch over to use pinctrl for pad init/config
> - Tidy up mixed case in FSP code
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Add bootstage timing for reading vbt
> - Add fspm_done() hook to handle FSP-S wierdness (it breaks SPI flash)
> - Don't allow BOOT_FROM_FAST_SPI_FLASH with FSP-S
> - Set boot_loader_tolum_size to 0
> - Use the IRQ uclass instead of ITSS
>
> Changes in v2: None
>
> arch/x86/cpu/apollolake/Makefile | 6 +
> arch/x86/cpu/apollolake/fsp_m.c | 210 ++
> arch/x86/cpu/apollolake/fsp_s.c | 667 +++
> 3 files changed, 883 insertions(+)
> create mode 100644 arch/x86/cpu/apollolake/fsp_m.c
> create mode 100644 arch/x86/cpu/apollolake/fsp_s.c
>
> diff --git a/arch/x86/cpu/apollolake/Makefile
> b/arch/x86/cpu/apollolake/Makefile
> index dc6df15dab..1760df54d8 100644
> --- a/arch/x86/cpu/apollolake/Makefile
> +++ b/arch/x86/cpu/apollolake/Makefile
> @@ -10,6 +10,12 @@ obj-y += cpu_common.o
> ifndef CONFIG_TPL_BUILD
> obj-y += cpu.o
> obj-y += punit.o
> +ifdef CONFIG_SPL_BUILD
> +obj-y += fsp_m.o
> +endif
> +endif
> +ifndef CONFIG_SPL_BUILD
> +obj-y += fsp_s.o
> endif
>
> obj-y += hostbridge.o
> diff --git a/arch/x86/cpu/apollolake/fsp_m.c b/arch/x86/cpu/apollolake/fsp_m.c
> new file mode 100644
> index 00..39cda7c49b
> --- /dev/null
> +++ b/arch/x86/cpu/apollolake/fsp_m.c
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 Google LLC
> + * Written by Simon Glass
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * ODT settings:
> + * If ODT PIN to LP4 DRAM is pulled HIGH for ODT_A and HIGH for ODT_B,
> + * choose ODT_A_B_HIGH_HIGH. If ODT PIN to LP4 DRAM is pulled HIGH for ODT_A
> + * and LOW for ODT_B, choose ODT_A_B_HIGH_LOW.
> + *
> + * Note that the enum values correspond to the interpreted UPD fields
> + * within Ch[3:0]_OdtConfig parameters.
> + */
> +enum {
> + ODT_A_B_HIGH_LOW= 0 << 1,
> + ODT_A_B_HIGH_HIGH = 1 << 1,
> + N_WR_24 = 1 << 5,
> +};
> +
> +/*
> + * LPDDR4 helper routines for configuring the memory UPD for LPDDR4
> operation.
> + * There are four physical LPDDR4 channels, each 32-bits wide. There are two
> + * logical channels using two physical channels together to form a 64-bit
> + * interface to memory for each logical channel.
> + */
> +
> +enum {
> + LP4_PHYS_CH0A,
> + LP4_PHYS_CH0B,
> + LP4_PHYS_CH1A,
> + LP4_PHYS_CH1B,
> +
> + LP4_NUM_PHYS_CHANNELS,
> +};
> +
> +/*
> + * The DQs within a physical channel can be bit-swizzled within each byte.
> + * Within a channel the bytes can be swapped, but the DQs need to be routed
> + * with the corresponding DQS (strobe).
> + */
> +enum {
> + LP4_DQS0,
> + LP4_DQS1,
> + LP4_DQS2,
> + LP4_DQS3,
> +
> + LP4_NUM_BYTE_LANES,
> + DQ_BITS_PER_DQS = 8,
> +};
> +
> +/* Provide bit swizzling per DQS and byte swapping within a channel */
> +struct lpddr4_chan_swizzle_cfg {
> + u8 dqs[LP4_NUM_BYTE_LANES][DQ_BITS_PER_DQS];
> +};
> +
> +struct lpddr4_swizzle_cfg {
> + struct lpddr4_chan_swizzle_cfg phys[LP4_NUM_PHYS_CHANNELS];
> +};
> +
> +static void setup_sdram(struct fsp_m_config *cfg,
> + const struct lpddr4_swizzle_cfg *swizzle_cfg)
> +{
> + const struct lpddr4_chan_swizzle_cfg *sch;
> + /* Number of bytes to copy per DQS */
> + const size_t sz = DQ_BITS_PER_DQS;
> + int chan;
> +
> + cfg->memory_down = 1;
> + cfg->scrambler_support = 1;
> + cfg->channel_hash_mask = 0x36;
> + cfg->slice_hash_mask = 9;
> + cfg->interleaved_mode = 2;
> + cfg->channels_slices_enable = 0;
> + cfg->min_ref_rate2x_enable = 0;
> + cfg->dual_rank_support_enable = 1;
> +
> + /* LPDDR4 is memory down so no SPD addresses */
> + cfg->dimm0_spd_address = 0;
> + cfg->dimm1_spd_address = 0;
> +
> + for (chan = 0; chan < 4; chan++) {
> + struct fsp_ram_channel *ch = &cfg->chan[chan];
> +
> + ch->rank_enable = 1;
> + ch->device_width = 1;
> + ch->dram_density = 2;
> + ch->option = 3;
> + ch->odt_config = ODT_A_B_HIGH_HIGH;
> + }
> +
> + /*
> +* CH0_DQB byte lanes in the bit swizzle configuration field are
> +* not 1:1. The mapping within the swizzling field is:
> +* indices [0:7] - byte lane 1 (DQS1)
Re: [U-Boot] [PATCH v5 101/101] x86: Add chromebook_coral
Hi Simon,
On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
>
> Add support for coral which is a range of Apollo Lake-based Chromebook
> released in 2017. This also includes reef released in 2016, since it is
> based on the same SoC.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v5:
> - Add gpio-controller to GPIO nodes
> - Comment out GPIOs in the fsp_s node since we don't use them yet
> - Correct CPU ACPI IDs
> - Use a define for ACPI base address
>
> Changes in v4:
> - Add u-boot,skip-auto-config-until-reloc property to PCI
> - Drop duplicate commit 'Create a new sandbox_pci_read_bar() function'
> - New GPIO driver binding
> - Set up LPC pads early
> - Switch over to use pinctrl for pad init/config
> - Update documentation with more detailed memory map
> - Use hyphen for device-tree properties
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Ad FSP-S support
> - Add CONFIG_TPL_X86_ASSUME_CPUID to reduce code size
> - Add Chrome OS EC support
> - Add a proper SPI node and make the SPI flash node a child
> - Add bootstage support
> - Add more documentation
> - Add spi alias in device tree
> - Disable the bootcommand since it does nothing useful on coral
> - Don't enable SPI flash in TPL by default
> - Drop CONFIG_SPL_NET_SUPPORT
> - Drop patch '86: timer: Reduce timer code size in TPL on Intel CPUs'
> - Drop patch 'dm: core: Don't include ofnode functions with of-platdata'
> - Drop patch 'spi: sandbox: Add a test driver for sandbox SPI flash'
> - Drop patch 'spl: Allow SPL/TPL to use of-platdata without libfdt'
> - Drop patch 'x86: apollolake: Add definitions for the Intel Fast SPI
> interface'
> - Drop patch 'x86: timer: Set up the timer in timer_early_get_count()'
> - Enable video and USB3
> - Reduce amount of early-pad data in TPL
> - Tidy up the pad settings in the device tree
> - Use a zero-based tsc timer
>
> Changes in v2: None
>
> arch/x86/dts/Makefile | 1 +
> arch/x86/dts/chromebook_coral.dts | 831 ++
> board/google/Kconfig | 15 +
> board/google/chromebook_coral/Kconfig | 43 ++
> board/google/chromebook_coral/MAINTAINERS | 6 +
> board/google/chromebook_coral/Makefile| 5 +
> board/google/chromebook_coral/coral.c | 18 +
> configs/chromebook_coral_defconfig| 102 +++
> doc/board/google/chromebook_coral.rst | 241 +++
> include/configs/chromebook_coral.h| 32 +
> 10 files changed, 1294 insertions(+)
> create mode 100644 arch/x86/dts/chromebook_coral.dts
> create mode 100644 board/google/chromebook_coral/Kconfig
> create mode 100644 board/google/chromebook_coral/MAINTAINERS
> create mode 100644 board/google/chromebook_coral/Makefile
> create mode 100644 board/google/chromebook_coral/coral.c
> create mode 100644 configs/chromebook_coral_defconfig
> create mode 100644 doc/board/google/chromebook_coral.rst
> create mode 100644 include/configs/chromebook_coral.h
>
> diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
> index d4bdf62be6..be209aaaf8 100644
> --- a/arch/x86/dts/Makefile
> +++ b/arch/x86/dts/Makefile
> @@ -2,6 +2,7 @@
>
> dtb-y += bayleybay.dtb \
> cherryhill.dtb \
> + chromebook_coral.dtb \
> chromebook_link.dtb \
> chromebox_panther.dtb \
> chromebook_samus.dtb \
> diff --git a/arch/x86/dts/chromebook_coral.dts
> b/arch/x86/dts/chromebook_coral.dts
> new file mode 100644
> index 00..583d5eb8bc
> --- /dev/null
> +++ b/arch/x86/dts/chromebook_coral.dts
> @@ -0,0 +1,831 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/dts-v1/;
> +
> +#include
> +
> +/include/ "skeleton.dtsi"
> +/include/ "keyboard.dtsi"
> +/include/ "reset.dtsi"
> +/include/ "rtc.dtsi"
> +/include/ "tsc_timer.dtsi"
> +
> +#ifdef CONFIG_CHROMEOS
> +#include "chromeos-x86.dtsi"
> +#include "flashmap-x86-ro.dtsi"
> +#include "flashmap-16mb-rw.dtsi"
> +#endif
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Google Coral";
> + compatible = "google,coral", "intel,apollolake";
> +
> + aliases {
> + cros-ec0 = &cros_ec;
> + fsp = &fsp_s;
> + spi0 = &spi;
> + };
> +
> + config {
> + silent_console = <0>;
> + };
> +
> + chosen {
> + stdout-path = &serial;
> + };
> +
> + cpus {
> + u-boot,dm-pre-reloc;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + u-boot,dm-pre-reloc;
> + device_type = "cpu";
> + compatible = "intel,apl-cpu";
> + reg = <0>;
> + intel,apic-id = <0>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "intel,apl-cpu";
> + reg = <1>;
> + intel,apic-
Re: [U-Boot] [PATCH v4 2/2] cmd: Add dtimg command
Dear Igor and Sam, Cc: Tom, Simon On Mon, Nov 18, 2019 at 10:27:32PM +0100, Eugeniu Rosca wrote: > Hello Igor, hello Sam, > > We still have high hopes getting your response to > https://patchwork.ozlabs.org/patch/958594/#2302310 > > If not given, we will proceed with implementing the proposal from > https://patchwork.ozlabs.org/patch/958594/#2303657 As the ones responsible for Android-specific patches, would you kindly review the functionality submitted to https://patchwork.ozlabs.org/cover/1202575/ ? In case you are not available in the next weeks, I hope Tom and Simon will suggest a way to go forward with the new patches? -- Best Regards, Eugeniu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong wrote: > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > wrote: > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support: > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) > > > > > > > > Adding support for ATF means that using U-Boot on Stratix10 and > > > > Agilex without ATF keeps working, right? > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work. > > > > Is there a technical requirement for that? > Yes. We are using ATF to provide PSCI services such as system reset (COLD > reset), > CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as > mailbox > communications with Secure Device Manager and accessing the System Manager > registers > which are secure. > Without PSCI services, we are able to boot until U-Boot proper only. > Currently, our U-Boot in > mainline doesn't boot to Linux due to these missing PSCI services. > Another reason is we have another boot flow which is using ATF + UEFI. So now > we are > re-using the PSCI services from ATF so that now U-Boot and UEFI share the > same ATF-BL31 > image so that we don't have to reimplement another sets of PSCI services for > U-Boot again. > This will greatly reduce our engineering efforts. Hmm, thanks for the explanation. I don't really think I can review this, given the lack of knowledge about that PSCI stuff. I must say it seems strange to me that U-Boot would have to rely on ATF though. How do other platforms implement this? Shouldn't PSCI be generic or is it really platform specific? If it's generic, isn't that a dupliation of code if you implement e.g. a reset driver for Stratix10 but call into PSCI? Regards, Simon > > > > Regard, > > Simon > > > > > > > > > > > > SPL loads the u-boot.itb which consist of: > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image) > > > > > 2) u-boot.dtb (U-Boot Proper DTB) > > > > > 3) bl31.bin (ATF-BL31 image) > > > > > > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) > > > > > > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes > > > > > SMC/PSCI calls provided by ATF to perform COLD reset, System > > > > > Manager register accesses and mailbox communications with Secure > > > > > Device Manager (SDM). > > > > > > > > > > Steps to build the U-Boot with ATF support: > > > > > 1) Build U-Boot > > > > > 2) Build ATF BL31 > > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder > > > > > 4) "make u-boot.itb" to generate u-boot.itb > > > > > > > > > > These patchsets have dependency on: > > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support: > > > > > https://patchwork.ozlabs.org/cover/1201373/ > > > > > > > > > > Chee Hong Ang (19): > > > > > arm: socfpga: add fit source file for pack itb with ATF > > > > > arm: socfpga: Add function for checking description from FIT image > > > > > arm: socfpga: Load FIT image with ATF support > > > > > arm: socfpga: Override 'lowlevel_init' to support ATF > > > > > configs: socfpga: Enable FIT image loading with ATF support > > > > > arm: socfpga: Disable "spin-table" method for booting Linux > > > > > arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) > > > > > arm: socfpga: Define SMC function identifiers for PSCI SiP services > > > > > arm: socfpga: Add secure register access helper functions for SoC > > > > > 64bits > > > > > arm: socfpga: Secure register access for clock manager (SoC 64bits) > > > > > arm: socfpga: Secure register access in PHY mode setup > > > > > arm: socfpga: Secure register access for reading PLL frequency > > > > > mmc: dwmmc: socfpga: Secure register access in MMC driver > > > > > net: designware: socfpga: Secure register access in MAC driver > > > > > arm: socfpga: Secure register access in Reset Manager driver > > > > > arm: socfpga: stratix10: Initialize timer in SPL > > > > > arm: socfpga: stratix10: Refactor FPGA reconfig driver to support > > > > > ATF > > > > > arm: socfpga: Bridge reset now invokes SMC calls to query FPGA > > > > > config > > > > > status > > > > > sysreset: socfpga: Invoke PSCI call for COLD reset > > > > > > > > > > Dalon Westergreen (1): > > > > > configs: stratix10: Remove CONFIG_OF_EMBED > > > > > > > > This one is included in another series already: > > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976 > > > > > > > > Does this mean that one will be abandonen? > > > > So the combined hex output part of that series is not required any more? > > > > > > > > Regards, > > > > Simon > > > > > > > > > > > > > > arch/arm/mach-socfpga/Kconfig | 2 - > > > > > arch/arm/mach-socfpga/Makefile | 4 + > > > > > arch/arm/mach-socfpga/board.c | 10 + > > > > > arch/arm/mach-socfpga/clock_manager_agilex
[U-Boot] [PATCH] iminfo: add missing map_sysmem
The command iminfo fails on sandbox because the address
is used directly. To fix this issue, we call the function
map_sysmem to translate the address.
Signed-off-by: Philippe Reynes
---
cmd/bootm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/cmd/bootm.c b/cmd/bootm.c
index 8279f2b..62ee7c4 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -244,7 +245,7 @@ static int do_iminfo(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
static int image_info(ulong addr)
{
- void *hdr = (void *)addr;
+ void *hdr = (void *)map_sysmem(addr, 0);
printf("\n## Checking Image at %08lx ...\n", addr);
@@ -254,11 +255,13 @@ static int image_info(ulong addr)
puts(" Legacy image found\n");
if (!image_check_magic(hdr)) {
puts(" Bad Magic Number\n");
+ unmap_sysmem(hdr);
return 1;
}
if (!image_check_hcrc(hdr)) {
puts(" Bad Header Checksum\n");
+ unmap_sysmem(hdr);
return 1;
}
@@ -267,15 +270,18 @@ static int image_info(ulong addr)
puts(" Verifying Checksum ... ");
if (!image_check_dcrc(hdr)) {
puts(" Bad Data CRC\n");
+ unmap_sysmem(hdr);
return 1;
}
puts("OK\n");
+ unmap_sysmem(hdr);
return 0;
#endif
#if defined(CONFIG_ANDROID_BOOT_IMAGE)
case IMAGE_FORMAT_ANDROID:
puts(" Android image found\n");
android_print_contents(hdr);
+ unmap_sysmem(hdr);
return 0;
#endif
#if defined(CONFIG_FIT)
@@ -284,6 +290,7 @@ static int image_info(ulong addr)
if (!fit_check_format(hdr)) {
puts("Bad FIT image format!\n");
+ unmap_sysmem(hdr);
return 1;
}
@@ -291,9 +298,11 @@ static int image_info(ulong addr)
if (!fit_all_image_verify(hdr)) {
puts("Bad hash in FIT image!\n");
+ unmap_sysmem(hdr);
return 1;
}
+ unmap_sysmem(hdr);
return 0;
#endif
default:
@@ -301,6 +310,7 @@ static int image_info(ulong addr)
break;
}
+ unmap_sysmem(hdr);
return 1;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] Pull request: u-boot-stm32 u-boot-stm32-20191126
On Wed, Nov 27, 2019 at 01:42:24PM +, Patrick DELAUNAY wrote: > Hi Tom > > Please pull the STM32 related patches for u-boot-stm32-20191126 > > With the following changes: > - Solve warning for stih410-b2260 > - Device tree alignment on v5.4-rc4 for all stm32 boards > - Correct the eMMC pin configuration on stm32mp157c-ev1 > - Add DFU and SPI-NAND support for stm32mp1 board > > Travis CI status: > https://travis-ci.org/patrickdelaunay/u-boot/builds/617166580 > > Thanks, > Patrick > > The following changes since commit 4b19b89ca4a866b7baa642533e6dbd67cd832d27: > > Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot (2019-11-25 > 12:56:27 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20191126 > > for you to fetch changes up to b4fee1610864036c8363e552f8547e99b1100f0b: > > stm32mp1: add support for virtual partition read (2019-11-26 10:14:35 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] pull request u-boot-mpc85xx
On Tue, Nov 26, 2019 at 04:49:39AM +, Priyanka Jain wrote: > Dear Tom, > > Please find my pull-request for u-boot-mpc85xx/master > https://travis-ci.org/p-priyanka-jain/u-boot/builds/616526169 > > Summary > powerpc: Fix DM_MMC related build warnings by adding > eSDHC device module support for T4240RDB, T2080RDB, T1042D4RDB, > T1024RDB, P5040DS, P4080DS, P3041DS, P2041RDB, P2020RDB, > P1020RDB platforms > > priyankajain Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull mmc-11-27-2019
On Thu, Nov 28, 2019 at 01:20:07AM +, Peng Fan wrote: > Hi Tom, > > Please pull mmc-11-27-2019 > CI: https://travis-ci.org/MrVan/u-boot/builds/617615361 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Thu, Nov 28, 2019 at 11:17:58AM +0100, Marek Vasut wrote: > The following changes since commit 9a0cbae22a613dfd55e15565785749b74c19fdf0: > > Merge tag 'u-boot-rockchip-20191124' of > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip (2019-11-23 > 20:50:11 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to a1a9843a29672be49a5bbb3a07fea8dbc88369ba: > > ARM: socfpga: Unreset NAND in SPL on Gen5 (2019-11-25 13:12:56 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Thu, Nov 28, 2019 at 11:17:36AM +0100, Marek Vasut wrote: > The following changes since commit 9a0cbae22a613dfd55e15565785749b74c19fdf0: > > Merge tag 'u-boot-rockchip-20191124' of > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip (2019-11-23 > 20:50:11 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to dbcbdad92caf4b42a6279da6e65180532bc45620: > > sandbox: enable USB_KEYBOARD_FN_KEYS (2019-11-25 13:28:53 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > >
> > > wrote:
> > > >
> > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote:
> > > > > >
> > > > > > From: "Ang, Chee Hong"
> > > > > >
> > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > > (EL1)
> > > > >
> > > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > > Agilex without ATF keeps working, right?
> > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > >
> > > Is there a technical requirement for that?
> > Yes. We are using ATF to provide PSCI services such as system reset
> > (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure
> > services such as mailbox communications with Secure Device Manager and
> > accessing the System Manager registers which are secure.
> > Without PSCI services, we are able to boot until U-Boot proper only.
> > Currently, our U-Boot in mainline doesn't boot to Linux due to these missing
> PSCI services.
> > Another reason is we have another boot flow which is using ATF + UEFI.
> > So now we are re-using the PSCI services from ATF so that now U-Boot
> > and UEFI share the same ATF-BL31 image so that we don't have to
> reimplement another sets of PSCI services for U-Boot again.
> > This will greatly reduce our engineering efforts.
>
> Hmm, thanks for the explanation.
>
> I don't really think I can review this, given the lack of knowledge about
> that PSCI
> stuff.
I believe you can review it.
Have you briefly gone through the patches ? It has nothing to do with the PSCI
stuff.
It just call the invoke_smc() function to call the ATF's PSCI functions. Those
PSCI
functions in ATF will do the rest.
>
> I must say it seems strange to me that U-Boot would have to rely on ATF
> though.
> How do other platforms implement this? Shouldn't PSCI be generic or is it
> really
> platform specific? If it's generic, isn't that a dupliation of code if you
> implement
> e.g. a reset driver for Stratix10 but call into PSCI?
It's not strange at all. A lot of U-Boot users already using this boot flow
(ATF + U-Boot).
Yes. PSCI is a generic software interface which encapsulate the platform
specific code.
Let me give you a good example in one of your sysreset driver you have
implemented for S10.
#include
#include
#include
-#include
static int socfpga_sysreset_request(struct udevice *dev,
enum sysreset_t type)
{
- puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
- mbox_reset_cold();
+ psci_system_reset();
return -EINPROGRESS;
}
Above is the changes in one of my patchsets, the sysreset driver for S10
used to call mbox_reset_cold() to send mailbox message to Secure Device Manager
(SDM) to trigger COLD reset.
Calling 'mbox_reset_cold()' means you are calling platform specific code in
the sysreset driver to perform COLD reset. What if method to trigger COLD reset
is changed in new platform ?
We have to change the sysreset driver code to support another new platform.
If this function call is replaced with "psci_system_reset()", we don't have to
change the code
at all because all the platform specific code for COLD reset is now reside in
ATF because this function
just invoke the PSCI function provided by ATF. You just have to replace the ATF
binary with the new
implementation for the new platform. We can re-use this sysreset driver for
any platform that support ATF. In fact, it makes our U-Boot driver code more
'generic' because PSCI
interface stay the same. BTW, Linux also call PSCI functions to perform COLD
reset. By using ATF,
U-Boot and Linux share the same COLD reset service provided by ATF. It actually
reduce
code duplication.
I think you are aware of we are working to move the mailbox driver code away
from arch to drivers.
You will see that a lot of those mailbox functions will be removed from the
mailbox driver.
One of them is 'mbox_reset_cold()' which you called in sysreset driver for S10.
> Regards,
> Simon
>
> > >
> > > Regard,
> > > Simon
> > >
> > > > > >
> > > > > > SPL loads the u-boot.itb which consist of:
> > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > > 3) bl31.bin (ATF-BL31 image)
> > > > > >
> > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > > >
> > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > > > invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> > > > > > System Manager register accesses and mailbox communications
> > > > > > with Secure Device Manager (SDM).
> > > > > >
> > > > > > Steps to build the U-Boot with ATF support:
> > > > > > 1) Build U-Boot
> > > > > > 2) Build ATF BL31
> > > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > > 4) "make u-boot.it
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong wrote:
>
> > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > wrote:
> > >
> > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > >
> > > > wrote:
> > > > >
> > > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote:
> > > > > > >
> > > > > > > From: "Ang, Chee Hong"
> > > > > > >
> > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > > > (EL1)
> > > > > >
> > > > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > > > Agilex without ATF keeps working, right?
> > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > >
> > > > Is there a technical requirement for that?
> > > Yes. We are using ATF to provide PSCI services such as system reset
> > > (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure
> > > services such as mailbox communications with Secure Device Manager and
> > > accessing the System Manager registers which are secure.
> > > Without PSCI services, we are able to boot until U-Boot proper only.
> > > Currently, our U-Boot in mainline doesn't boot to Linux due to these
> > > missing
> > PSCI services.
> > > Another reason is we have another boot flow which is using ATF + UEFI.
> > > So now we are re-using the PSCI services from ATF so that now U-Boot
> > > and UEFI share the same ATF-BL31 image so that we don't have to
> > reimplement another sets of PSCI services for U-Boot again.
> > > This will greatly reduce our engineering efforts.
> >
> > Hmm, thanks for the explanation.
> >
> > I don't really think I can review this, given the lack of knowledge about
> > that PSCI
> > stuff.
> I believe you can review it.
> Have you briefly gone through the patches ? It has nothing to do with the
> PSCI stuff.
> It just call the invoke_smc() function to call the ATF's PSCI functions.
> Those PSCI
> functions in ATF will do the rest.
No, not yet. But see below.
> >
> > I must say it seems strange to me that U-Boot would have to rely on ATF
> > though.
> > How do other platforms implement this? Shouldn't PSCI be generic or is it
> > really
> > platform specific? If it's generic, isn't that a dupliation of code if you
> > implement
> > e.g. a reset driver for Stratix10 but call into PSCI?
> It's not strange at all. A lot of U-Boot users already using this boot flow
> (ATF + U-Boot).
Just because other boards do this doesn't mean it's not strange. Wasn't there
some kind of discussion around that PSCI stuff to make it available from U-Boot?
What's wrong with that way?
In my opinion, you're reducing functionality in U-Boot by making ATF a
requirement.
And by saying "I can't review this", I mean this looks like a
questionable way to me
and I'm not the one to say if a U-Boot board should go this way or not.
> Yes. PSCI is a generic software interface which encapsulate the platform
> specific code.
> Let me give you a good example in one of your sysreset driver you have
> implemented for S10.
>
> #include
> #include
> #include
> -#include
>
> static int socfpga_sysreset_request(struct udevice *dev,
> enum sysreset_t type)
> {
> - puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> - mbox_reset_cold();
> + psci_system_reset();
So this is not an socfgpa_s10 specific driver any more, right?
> return -EINPROGRESS;
> }
>
> Above is the changes in one of my patchsets, the sysreset driver for S10
> used to call mbox_reset_cold() to send mailbox message to Secure Device
> Manager
> (SDM) to trigger COLD reset.
> Calling 'mbox_reset_cold()' means you are calling platform specific code in
> the sysreset driver to perform COLD reset. What if method to trigger COLD
> reset is changed in new platform ?
> We have to change the sysreset driver code to support another new platform.
> If this function call is replaced with "psci_system_reset()", we don't have
> to change the code
> at all because all the platform specific code for COLD reset is now reside in
> ATF because this function
> just invoke the PSCI function provided by ATF. You just have to replace the
> ATF binary with the new
> implementation for the new platform. We can re-use this sysreset driver for
> any platform that support ATF. In fact, it makes our U-Boot driver code more
> 'generic' because PSCI
> interface stay the same. BTW, Linux also call PSCI functions to perform COLD
> reset. By using ATF,
> U-Boot and Linux share the same COLD reset service provided by ATF. It
> actually reduce
> code duplication.
What I meant was code duplication inside the U-Boot tree (having one
driver for each
arch but in effect all those drivers will call into the same psci function).
What you're doing is to move this code from U-Boot open U-Boot sources
to possibly
closed source ATF sources. But we've already had that discussion, I think...
Regards,
Simon
>
> I think you
Re: [U-Boot] [PATCH] arm: dts: bcm283x: Allow UARTs to work before relocation
On Sun, Dec 01, 2019 at 07:33:56PM -0700, Simon Glass wrote:
> At present the pinctrl nodes are not enabled in pre-relocation U-Boot so
> the UARTs do not correctly select the pinconfig to enable the UART pins.
> Fix this so that the U-Boot banner is printed.
>
> Signed-off-by: Simon Glass
> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
> ---
>
> arch/arm/dts/bcm283x-u-boot.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
> b/arch/arm/dts/bcm283x-u-boot.dtsi
> index 36548dad62..68d03627f4 100644
> --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> @@ -19,3 +19,11 @@
> &gpio {
> u-boot,dm-pre-reloc;
> };
> +
> +&uart0_gpio14 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart1_gpio14 {
> + u-boot,dm-pre-reloc;
> +};
I think this is superseded by the RPi PR that I had been testing and
just now pushed. Can you confirm that master is fine on your Pis as
well? I gather you hit this failure doing pytest on the board, which is
also how I found it. Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2] blk: Make use of CONFIG_HAVE_BLOCK_DEVICE more
When we do not have CONFIG_BLK (or SPL/TPL) enabled there are very few
cases where we need the blk_legacy code linked in. To catch these, build
when we have CONFIG_HAVE_BLOCK_DEVICE set. In addition, we only need
cmd/blk_common.o to be linked in when we have CONFIG_HAVE_BLOCK_DEVICE
set, so make use of that directly.
Signed-off-by: Tom Rini
---
Changes in v2:
- Reword commit message and make blk_legacy.o also use
CONFIG_HAVE_BLOCK_DEVICE rather than CONFIG_PARTITIONS as it is more
direct.
---
cmd/Makefile | 2 +-
cmd/blk_common.c | 2 --
drivers/block/Makefile | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/cmd/Makefile b/cmd/Makefile
index 2d723ea0f07d..f823d16755e6 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_CMD_AES) += aes.o
obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
obj-$(CONFIG_CMD_ADC) += adc.o
obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
-obj-y += blk_common.o
+obj-$(CONFIG_HAVE_BLOCK_DEVICE) += blk_common.o
obj-$(CONFIG_CMD_SOURCE) += source.o
obj-$(CONFIG_CMD_BCB) += bcb.o
obj-$(CONFIG_CMD_BDI) += bdinfo.o
diff --git a/cmd/blk_common.c b/cmd/blk_common.c
index cee25a0d4100..c5514cf8f8e8 100644
--- a/cmd/blk_common.c
+++ b/cmd/blk_common.c
@@ -11,7 +11,6 @@
#include
#include
-#ifdef CONFIG_HAVE_BLOCK_DEVICE
int blk_common_cmd(int argc, char * const argv[], enum if_type if_type,
int *cur_devnump)
{
@@ -96,4 +95,3 @@ int blk_common_cmd(int argc, char * const argv[], enum
if_type if_type,
}
}
}
-#endif
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 3feb0aa997df..94ab5c6f906e 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -6,7 +6,7 @@
obj-$(CONFIG_$(SPL_)BLK) += blk-uclass.o
ifndef CONFIG_$(SPL_)BLK
-obj-y += blk_legacy.o
+obj-$(CONFIG_HAVE_BLOCK_DEVICE) += blk_legacy.o
endif
ifndef CONFIG_SPL_BUILD
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spl: Allow cache drivers to be used in SPL
On Fri, Nov 29, 2019 at 09:59:26AM +0800, Ley Foon Tan wrote: > Add an option for building cache drivers in SPL. > > Signed-off-by: Ley Foon Tan > Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test.py: Make search for autoconf.mk more permission
On 12/1/19 7:34 PM, Simon Glass wrote: Buildman doesn't store this file in the same directory as a normal build. Update the conftest code to handle both cases. Shouldn't we just fix buildman so that it puts the files in the standard locations? That way, we don't have to separately update every tool that might want to find/interpret this file or archive the build results, but instead just update one tool (buildman). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] One u-boot.bin for Raspberry PI 3 and 4 - possible?
Hi Geoff, On 03/10/2019 03:44, Geoff Williams wrote: >> And with a U-Boot based on f5c626c64874d6e1482edf4a76aa22e5e54be63d without >> my >> patches you see correct behavior? > > The screen turning off issue was caused by a deployment script copying the > wrong > u-boot binary to the SD card! The patch does not introduce a regression on > RPI 3 > (tested before/after patch). > > Once I switched over to the the real u-boot image the grub graphical font > didn't > load (irrespective of patch) I was able to fix this by changing the > rpi_3_defconfig: > > -CONFIG_OF_EMBED=y > -CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" > +CONFIG_OF_BOARD=y > > I suspect my issues are to do with DTBs and that all these problems will go > away > once a single defconfig is available. The screen turning off issue I have no > idea about but its from a much older version of u-boot and probably relates to > something in the image I built. > In U-Boot master you should find now a rpi_arm64_defconfig which should boot on both RPi3 and RPi4. Regards, Matthias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > >
> > > wrote:
> > > >
> > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > > On Mon, Dec 2, 2019 at 11:25 AM
> wrote:
> > > > > > > >
> > > > > > > > From: "Ang, Chee Hong"
> > > > > > > >
> > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > > > > > > Linux
> > > > > > > > (EL1)
> > > > > > >
> > > > > > > Adding support for ATF means that using U-Boot on Stratix10
> > > > > > > and Agilex without ATF keeps working, right?
> > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > > >
> > > > > Is there a technical requirement for that?
> > > > Yes. We are using ATF to provide PSCI services such as system
> > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > > > other secure services such as mailbox communications with Secure
> > > > Device Manager and accessing the System Manager registers which are
> secure.
> > > > Without PSCI services, we are able to boot until U-Boot proper only.
> > > > Currently, our U-Boot in mainline doesn't boot to Linux due to
> > > > these missing
> > > PSCI services.
> > > > Another reason is we have another boot flow which is using ATF + UEFI.
> > > > So now we are re-using the PSCI services from ATF so that now
> > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > > > have to
> > > reimplement another sets of PSCI services for U-Boot again.
> > > > This will greatly reduce our engineering efforts.
> > >
> > > Hmm, thanks for the explanation.
> > >
> > > I don't really think I can review this, given the lack of knowledge
> > > about that PSCI stuff.
> > I believe you can review it.
> > Have you briefly gone through the patches ? It has nothing to do with the
> > PSCI
> stuff.
> > It just call the invoke_smc() function to call the ATF's PSCI
> > functions. Those PSCI functions in ATF will do the rest.
>
> No, not yet. But see below.
>
> > >
> > > I must say it seems strange to me that U-Boot would have to rely on ATF
> though.
> > > How do other platforms implement this? Shouldn't PSCI be generic or
> > > is it really platform specific? If it's generic, isn't that a
> > > dupliation of code if you implement e.g. a reset driver for Stratix10 but
> > > call
> into PSCI?
> > It's not strange at all. A lot of U-Boot users already using this boot
> > flow (ATF +
> U-Boot).
>
> Just because other boards do this doesn't mean it's not strange. Wasn't there
> some kind of discussion around that PSCI stuff to make it available from
> U-Boot?
> What's wrong with that way?
Our downstream U-Boot branch is already implemented the PSCI stuffs in U-Boot.
I tried to upstream my PSCI code:
https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
Marek pointed me to this thread:
https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html
He had a point. He suggested maybe we can implement the PSCI stuffs in SPL/TPL.
I took a look at the U-Boot code and found out
ATF is already well supported. Why don't we just use the PSCI code from ATF
rather than re-implementing the PSCI code again in SPL/TPL.
It will save our effort to maintain two PSCI code in U-Boot and ATF while we
already have the ATF PSCI implementation to support UEFI.
>
> In my opinion, you're reducing functionality in U-Boot by making ATF a
> requirement.
>
> And by saying "I can't review this", I mean this looks like a questionable
> way to
> me and I'm not the one to say if a U-Boot board should go this way or not.
I understand. Btw, who should I include to review this ?
>
> > Yes. PSCI is a generic software interface which encapsulate the platform
> specific code.
> > Let me give you a good example in one of your sysreset driver you have
> implemented for S10.
> >
> > #include
> > #include
> > #include
> > -#include
> >
> > static int socfpga_sysreset_request(struct udevice *dev,
> > enum sysreset_t type) {
> > - puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > - mbox_reset_cold();
> > + psci_system_reset();
>
> So this is not an socfgpa_s10 specific driver any more, right?
>
> > return -EINPROGRESS;
> > }
> >
> > Above is the changes in one of my patchsets, the sysreset driver for
> > S10 used to call mbox_reset_cold() to send mailbox message to Secure
> > Device Manager
> > (SDM) to trigger COLD reset.
> > Calling 'mbox_reset_cold()' means you are calling platform specific
> > code in the sysreset driver to perform COLD reset. What if method to trigger
> COLD reset is changed in new platform ?
> > We have to change the sysreset driver code to support another new platform.
> > If this function call is replaced with "psci_system_reset()", we don't
> > have to change the code at all because all the
[U-Boot] [PATCH] cmd: cp: add missing map_sysmem
The command cp fails on sandbox because the address is used
directly. To fix this issue, we call the function map_sysmem
to translate the address.
Signed-off-by: Philippe Reynes
---
cmd/mem.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/cmd/mem.c b/cmd/mem.c
index c6b8038..1757c84 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -303,6 +303,7 @@ static int do_mem_cmp(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
ulong addr, dest, count;
+ void*src, *dst;
int size;
if (argc != 4)
@@ -326,25 +327,34 @@ static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
return 1;
}
+ src = map_sysmem(addr, count * size);
+ dst = map_sysmem(dest, count * size);
+
#ifdef CONFIG_MTD_NOR_FLASH
/* check if we are copying to Flash */
- if (addr2info(dest) != NULL) {
+ if (addr2info((ulong)dst)) {
int rc;
puts ("Copy to Flash... ");
- rc = flash_write ((char *)addr, dest, count*size);
+ rc = flash_write((char *)src, (ulong)dst, count * size);
if (rc != 0) {
flash_perror (rc);
+ unmap_sysmem(src);
+ unmap_sysmem(dst);
return (1);
}
puts ("done\n");
+ unmap_sysmem(src);
+ unmap_sysmem(dst);
return 0;
}
#endif
- memcpy((void *)dest, (void *)addr, count * size);
+ memcpy(dst, src, count * size);
+ unmap_sysmem(src);
+ unmap_sysmem(dst);
return 0;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21
On 22/11/19 07:42, Peng Fan wrote: > Hi Stefano, > > Please pull imx-master-11-21, based on imx/master. > CI: https://travis-ci.org/MrVan/u-boot/builds/614830163 > > > i.mx6qp noc settings > i.mx7ulp update and artists com board support > > > Thanks, > Peng. > About mx7ulp (and warp7, Tom has merged this one: commit a09fea1d28fe3c69a64bee092f5a764274d26ca2 Author: Tom Rini Date: Mon Nov 18 20:02:10 2019 -0500 env: Finish migration of common ENV options This drop CONFIG_ENV_SIZE from boards' header. If I merge your PR and the fix for warp7, I will reintroduce the CONFIG_ENV_*Ü, and it is like to do against Tom's patch. I think you should rework them to avoid the reintroduction in the header file. I will just pick up myself i.mx6qp patch. Regards, Stefano > The following changes since commit bdcf3a88cc582ce8bb9ea024fa917d9a52e05479: > > imx: imx8mm-evk: enable ethernet (2019-11-05 10:27:18 +0100) > > are available in the Git repository at: > > https://github.com/MrVan/u-boot.git imx-master-11-21 > > for you to fetch changes up to 153d06d07d6827460e62045bd51083e64a727648: > > mx6cuboxi: Add Baruch as maintainer (2019-11-21 09:50:23 +0800) > > > Fabio Estevam (8): > mx6: Allow configuring the NoC registers on i.MX6QP > mx7ulp: Print the LDO mode status > mx7ulp: Introduce the CONFIG_LDO_ENABLED_MODE option > mx7ulp: Remove the _RUN notation from the PMC1 LDOVL definitions > mx7ulp: scg: Remove unnused scg_a7_apll_init() > mx7ulp: Sync the device tree related files > mx7ulp: Add support for Embedded Artists COM board > mx6cuboxi: Add Baruch as maintainer > > arch/arm/dts/Makefile |3 +- > arch/arm/dts/imx7ulp-com.dts | 90 +++ > arch/arm/dts/imx7ulp-evk.dts | 157 +--- > arch/arm/dts/imx7ulp-pinfunc.h | 1748 > ++-- > arch/arm/dts/imx7ulp.dtsi | 28 ++- > arch/arm/include/asm/arch-mx7ulp/scg.h |1 - > arch/arm/mach-imx/mx6/soc.c| 35 +++ > arch/arm/mach-imx/mx7ulp/Kconfig | 11 + > arch/arm/mach-imx/mx7ulp/scg.c | 61 - > arch/arm/mach-imx/mx7ulp/soc.c | 78 ++ > board/ea/mx7ulp_com/Kconfig| 12 + > board/ea/mx7ulp_com/MAINTAINERS|6 + > board/ea/mx7ulp_com/Makefile |6 + > board/ea/mx7ulp_com/imximage.cfg | 128 ++ > board/ea/mx7ulp_com/mx7ulp_com.c | 48 > board/solidrun/mx6cuboxi/MAINTAINERS |1 + > configs/mx7ulp_com_defconfig | 59 + > include/configs/mx7ulp_com.h | 107 + > 18 files changed, 1552 insertions(+), 1027 deletions(-) > create mode 100644 arch/arm/dts/imx7ulp-com.dts > create mode 100644 board/ea/mx7ulp_com/Kconfig > create mode 100644 board/ea/mx7ulp_com/MAINTAINERS > create mode 100644 board/ea/mx7ulp_com/Makefile > create mode 100644 board/ea/mx7ulp_com/imximage.cfg > create mode 100644 board/ea/mx7ulp_com/mx7ulp_com.c > create mode 100644 configs/mx7ulp_com_defconfig > create mode 100644 include/configs/mx7ulp_com.h > -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/8] image: android: Add functions for handling dtb field
Hi Eugeniu,
On Tue, Oct 29, 2019 at 3:49 AM Eugeniu Rosca wrote:
>
> Hi Sam,
>
> On Wed, Oct 23, 2019 at 05:34:20PM +0300, Sam Protsenko wrote:
> > Android Boot Image v2 adds "DTB" payload (and corresponding field in the
> > image header). Provide functions for its handling:
>
> I believe this totally new degree of freedom brought by "Android Boot
> Image v2" might unintentionally make some users more unhappy [0], since
> it enables yet another way of passing a DTB to the Android kernel.
>
> It looks to me that there are at least three valid design choices for
> DTB storage/passing which platform maintainers have to consider:
> A. Android Image second area [1-2]
> B. Dedicated DTB/DTBO partitions on a block device
> C. DTB area in Android Image v2
>
> While there are some major disadvantages for [A][1-2], [B] and [C] look
> more or less equivalent and will most likely only differ in the tooling
> used to generate and extract the useful/relevant artifacts.
>
> Not to mention that hybrids [B+C] are also possible.
> Which solution should we pick as a long-term one?
>
My opinion is next: we should provide means (commands) to achieve any
of [A,B,C] options. Then user (I mean, U-Boot developer who implements
boot for each particular board) should decide which approach to use.
Also [D] FIT image can be used instead of Android Boot Image. But we
should remember that Google requires *mandatory* for all *new* devices
(starting with Android 10) to stick with [C] approach only. Option [B]
might be harder to handle from AVB verification point of view. Btw,
when we come to "boot_android" command, I think we'll need to
implement only officially recommended boot method. Maybe provide a
param to choose whether to do Android-9 or Android-10 boot scheme.
Anyway, the short answer is: we should provide a bunch of isolated
commands to allow the user to implement any boot method.
Also, this particular patch doesn't change boot behavior (it only adds
functions to handle dtb field), so it should be backward-compatible.
> [0] https://en.wikipedia.org/wiki/The_Paradox_of_Choice
> [1] 104816142f9c6a ("parse the second area of android image")
> [2] 6a7b406aa8b981 ("fdt: support booting with dtb in Android image")
>
> [..]
>
> > common/Makefile| 2 +-
> > common/image-android.c | 215 +
> > include/image.h| 5 +
> > 3 files changed, 221 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/Makefile b/common/Makefile
> > index 302d8beaf3..7e5f5058b3 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -108,7 +108,7 @@ endif
> >
> > obj-y += image.o
> > obj-$(CONFIG_ANDROID_AB) += android_ab.o
> > -obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
> > +obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o image-android-dt.o
>
> I expect that in a not so distant future, Android users who care
> about performance aspects of their system (e.g. in automotive sector,
> where boot time is paramount to achieve ~2s to Rear View Camera) will
> attempt optimizing U-Boot by compiling out features they don't need.
>
> With this background:
> - Would it make sense to allow users to selectively enable and disable
>support for A/B-capable and non-A/B devices? My guess is that it
>is currently not an important development/review criteria, since
>particularly image-android-dt.c implements functions, some of which
>are A/B-specific, some non-A/B-specific (e.g. android_image_get_dtbo)
>and some are common.
> - I would try to avoid wiring the same compilation unit to Kbuild
>(e.g. image-android-dt.o) via multiple Kconfig symbols
>(CONFIG_ANDROID_BOOT_IMAGE and CONFIG_CMD_DTIMG) since this makes
>the relationship between the CONFIG symbols unclear. As a user, I
>would like to see a simple mapping between compiled objects and
>Kconfig symbols, eventually reflecting a hierarchy/dependency:
>
>config ANDROID_BOOT_IMAGE
> select ANDROID_BOOT_IMAGE_DT
>
>config DTIMG
> select ANDROID_BOOT_IMAGE_DT
>
I thought about that 4 months ago when implementing this patch, even
experimented with that. But decided to just add image-android-dt.o in
Makefile instead, don't remember for what reason exactly. Frankly,
don't really want to go there again and spend too much time (at least
not in the context of this patch series).
So here is what I suggest: can we approach this one-step-at-a-time?
This patch-set is a major step as it is, and it takes a lot of time to
get it merged. What you suggest makes sense but might have some
implications (even architectural) when trying to implement that. Can
we do that in another series?
> [..]
>
> > diff --git a/common/image-android.c b/common/image-android.c
> > index 3564a64221..5e721a27a7 100644
> > --- a/common/image-android.c
> > +++ b/common/image-android.c
> > @@ -6,10 +6,12 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> >
Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21
Hi Stefano, On Mon, Dec 2, 2019 at 2:04 PM Stefano Babic wrote: > About mx7ulp (and warp7, > > Tom has merged this one: > > commit a09fea1d28fe3c69a64bee092f5a764274d26ca2 > Author: Tom Rini > Date: Mon Nov 18 20:02:10 2019 -0500 > > env: Finish migration of common ENV options > > This drop CONFIG_ENV_SIZE from boards' header. If I merge your PR and > the fix for warp7, I will reintroduce the CONFIG_ENV_*Ü, and it is like > to do against Tom's patch. I think you should rework them to avoid the > reintroduction in the header file. Could you please apply all the i.MX7ULP except the one that introduce the i.MX7ULP Embedded Artists COM board? I can rework this last patch to not have CONFIG_ENV_SIZE in the header file. Please let me know if you are OK with this. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/8] env: ti: boot: Boot Android with dynamic partitions
Hi Tom, On Sun, Nov 3, 2019 at 4:35 PM Tom Rini wrote: > > On Wed, Oct 23, 2019 at 05:34:26PM +0300, Sam Protsenko wrote: > > > Changes: > > - use boot.img instead of boot_fit.img > > - use .dtb from boot.img v2 > > - implement recovery boot > > - always boot ramdisk from boot.img, we can't mount system as root > > now, as system is a logical partition inside of super partition > > - don't add "skip_initramfs" to cmdline anymore > > - to boot into recovery, use boot image from recovery partition > > - prepare partition table: > > - A/B scheme > > - use 'super' partition instead of 'system' and 'vendor' > > - add dtbo partitions > > - introduce metadata partition > > > > Not implemented: reading and applying dtbo files from dtbo partition. > > > > Signed-off-by: Sam Protsenko > > This breaks at least "dra7xx_evm" building: >arm: + dra7xx_evm > +(dra7xx_evm) In file included from include/configs/ti_omap5_common.h:57:0, > +(dra7xx_evm) from include/configs/dra7xx_evm.h:62, > +(dra7xx_evm) from include/config.h:5, > +(dra7xx_evm) from include/common.h:23, > +(dra7xx_evm) from env/common.c:10: > +(dra7xx_evm) include/environment/ti/boot.h:104:3: error: expected '}' before > 'AB_SELECT_SLOT' > +(dra7xx_evm)AB_SELECT_SLOT \ > +(dra7xx_evm)^ > +(dra7xx_evm) include/configs/ti_omap5_common.h:65:2: note: in expansion of > macro 'DEFAULT_COMMON_BOOT_TI_ARGS' > +(dra7xx_evm) DEFAULT_COMMON_BOOT_TI_ARGS \ > +(dra7xx_evm) ^~~ > +(dra7xx_evm) include/env_default.h:111:2: note: in expansion of macro > 'CONFIG_EXTRA_ENV_SETTINGS' > +(dra7xx_evm) CONFIG_EXTRA_ENV_SETTINGS > +(dra7xx_evm) ^ > +(dra7xx_evm) make[2]: *** [env/common.o] Error 1 > +(dra7xx_evm) make[1]: *** [env] Error 2 > +(dra7xx_evm) make[1]: *** wait: No child processes. Stop. > +(dra7xx_evm) make: *** [sub-make] Error 2 > Thanks, will be fixed in new version. I should run buildman more often :) > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21
On 02/12/19 18:28, Fabio Estevam wrote: > Hi Stefano, > > On Mon, Dec 2, 2019 at 2:04 PM Stefano Babic wrote: > >> About mx7ulp (and warp7, >> >> Tom has merged this one: >> >> commit a09fea1d28fe3c69a64bee092f5a764274d26ca2 >> Author: Tom Rini >> Date: Mon Nov 18 20:02:10 2019 -0500 >> >> env: Finish migration of common ENV options >> >> This drop CONFIG_ENV_SIZE from boards' header. If I merge your PR and >> the fix for warp7, I will reintroduce the CONFIG_ENV_*Ü, and it is like >> to do against Tom's patch. I think you should rework them to avoid the >> reintroduction in the header file. > > Could you please apply all the i.MX7ULP except the one that introduce > the i.MX7ULP Embedded Artists COM board? > > I can rework this last patch to not have CONFIG_ENV_SIZE in the header file. > > Please let me know if you are OK with this. I am fine, thanks. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21
Hi Stefano, On Mon, Dec 2, 2019 at 2:40 PM Stefano Babic wrote: > I am fine, thanks. Excellent! Please ping me when all my i.MX7ULP patches have been applied to your tree and then I will submit an updated version of the i.MX7ULP Embedded Artists board patch. Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
