[U-Boot] [PATCH 1/2 v2] mips: mt76xx: Remove cache workaround and select SYS_MALLOC_CLEAR_ON_INIT
With commit 06985289d452 ("watchdog: Implement generic watchdog_reset()
version") the init sequence has changed in arch_misc_init(), resulting
in a re-appearance of the d-cache issue on MT7688 boards (e.g. gardena).
When this happens, the first (or sometimes later ones as well) TFTP
command hangs and does not complete correctly. This leads to the
assumption that the d-cache is not in a clean state once the ethernet
driver is called (d-cache is used here for the buffers). The old work-
around with the cache flush somehow does not work any more now with
the new code change.
To fix this issue, this patch now removes the old workaround and selects
CONFIG_SYS_MALLOC_CLEAR_ON_INIT for ARCH_MTMIPS. With this option the
complete malloc area is initialized with zeros (cache lines are touched).
Testing has shown that this also fixes the issue on the MT7688 boards.
Signed-off-by: Stefan Roese
Suggested-by: Daniel Schwierzeck
Cc: Daniel Schwierzeck
---
v2:
- As suggested by Daniel, remove the workaround (hack) and select
CONFIG_SYS_MALLOC_CLEAR_ON_INIT instead
arch/mips/Kconfig | 2 +-
arch/mips/mach-mtmips/cpu.c | 15 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9cf8e9800d..5cb9bdf2ee 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -84,13 +84,13 @@ config ARCH_MTMIPS
select DM_SERIAL
imply DM_SPI
imply DM_SPI_FLASH
- select ARCH_MISC_INIT
select MIPS_TUNE_24KC
select OF_CONTROL
select ROM_EXCEPTION_VECTORS
select SUPPORTS_CPU_MIPS32_R1
select SUPPORTS_CPU_MIPS32_R2
select SUPPORTS_LITTLE_ENDIAN
+ select SYS_MALLOC_CLEAR_ON_INIT
select SYSRESET
config ARCH_JZ47XX
diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c
index fcd0484a6d..b0a6397d68 100644
--- a/arch/mips/mach-mtmips/cpu.c
+++ b/arch/mips/mach-mtmips/cpu.c
@@ -68,18 +68,3 @@ int print_cpuinfo(void)
return 0;
}
-
-int arch_misc_init(void)
-{
- /*
-* It has been noticed, that sometimes the d-cache is not in a
-* "clean-state" when U-Boot is running on MT7688. This was
-* detected when using the ethernet driver (which uses d-cache)
-* and a TFTP command does not complete. Flushing the complete
-* d-cache (again?) here seems to fix this issue.
-*/
- flush_dcache_range(gd->bd->bi_memstart,
- gd->bd->bi_memstart + gd->ram_size - 1);
-
- return 0;
-}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2 v2] mips: mt76xx: gardena-smart-gateway: Enable CONFIG_USE_PREBOOT
Enable CONFIG_USE_PREBOOT on for the gardena mt7688 platforms, so that
this feature can be used here.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
---
v2:
- No change
configs/gardena-smart-gateway-mt7688-ram_defconfig | 1 +
configs/gardena-smart-gateway-mt7688_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig
b/configs/gardena-smart-gateway-mt7688-ram_defconfig
index e09950637f..ec47beaf1d 100644
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ b/configs/gardena-smart-gateway-mt7688-ram_defconfig
@@ -12,6 +12,7 @@ CONFIG_IMAGE_FORMAT_LEGACY=y
CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="cp.b 8300 8400 1 && dhcp uEnv.txt && env
import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
+CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_VERSION_VARIABLE=y
CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/gardena-smart-gateway-mt7688_defconfig
b/configs/gardena-smart-gateway-mt7688_defconfig
index ad0db2e723..cdc5221d6a 100644
--- a/configs/gardena-smart-gateway-mt7688_defconfig
+++ b/configs/gardena-smart-gateway-mt7688_defconfig
@@ -15,6 +15,7 @@ CONFIG_IMAGE_FORMAT_LEGACY=y
CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="cp.b 8300 8400 1 && dhcp uEnv.txt && env
import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
+CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_VERSION_VARIABLE=y
CONFIG_BOARD_EARLY_INIT_F=y
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH] i2c: pcf2127: fix bug that read wrong time
Hi Heiko,
> Hello Chuanhua Han,
>
> Am 22.05.2019 um 14:45 schrieb Chuanhua Han:
> >
> >
> >> -Original Message-
> >> From: Lukasz Majewski
> >> Sent: 2019年5月22日 19:32
> >> To: Chuanhua Han
> >> Cc: h...@denx.de; u-boot@lists.denx.de; Biwen Li ;
> >> s...@chromium.org; Stefano Babic
> >> Subject: Re: [EXT] Re: [PATCH] i2c: pcf2127: fix bug that read
> >> wrong time
> >>
> >> On Wed, 22 May 2019 09:31:35 +
> >> Chuanhua Han wrote:
> >>
> -Original Message-
> From: Lukasz Majewski
> Sent: 2019年5月22日 16:41
> To: Chuanhua Han
> Cc: h...@denx.de; u-boot@lists.denx.de; Biwen Li
> ; s...@chromium.org; Stefano Babic
> Subject: Re: [EXT] Re: [PATCH] i2c: pcf2127:
> fix bug that read wrong time
>
> Hi Chuanhua,
>
> >> -Original Message-
> >> From: Lukasz Majewski
> >> Sent: 2019年5月22日 15:16
> >> To: Chuanhua Han
> >> Cc: h...@denx.de; u-boot@lists.denx.de; Biwen Li
> >> ; s...@chromium.org
> >> Subject: [EXT] Re: [PATCH] i2c: pcf2127: fix bug that read
> >> wrong time
> >>
> >> Hi Chuanhua,
> >>
> >>> Because i2c driver does not generate a stop bit when reading
> >>> registers of pcf2127
> >>
> >> The change (in the common i2c code) is rather large when
> >> considering the description above.
> >>
> >> Could you write a more detailed patch description? Is this only
> >> the problem with i2c in DM?
> > OK, This is a problem with the i2c transport framework. After
> > writing the register address that you want to read, the stop
> > signal is missing before reading the register data.
> >>
> >> Is the same code (as introduced in this commit) available in
> >> Linux kernel?
> > The kernel does not have such a problem
>
> Do you know maybe why such issue is not present on Linux
> kernel?
> >>> The kernel code is encapsulated when reading the pcf2127 register,
> >>> which separates the read and write, thus generating a stop signal
> >>> before reading the register. Eg: Here is the wrapper made by the
> >>> kernel code: static int pcf2127_i2c_read(void *context, const void
> >>> *reg, size_t reg_size, void *val, size_t val_size) {
> >>> struct device *dev = context;
> >>> struct i2c_client *client = to_i2c_client(dev);
> >>> int ret;
> >>>
> >>> if (WARN_ON(reg_size != 1))
> >>> return -EINVAL;
> >>>
> >>> ret = i2c_master_send(client, reg, 1);
> >>> if (ret != 1)
> >>> return ret < 0 ? ret : -EIO;
> >>>
> >>> ret = i2c_master_recv(client, val, val_size);
> >>> if (ret != val_size)
> >>> return ret < 0 ? ret : -EIO;
> >>>
> >>> return 0;
> >>> }
> >>
> >> That was my point - the same shall be done in the pcf2127 driver.
> >> This is a slow device, so we can afford for this.
> > There is no similar api in the uboot code to split the read data
> > into the address of the send register and receive the data. Uboot
> > encapsulates the transmit register address and the read data, so no
> > stop signal is generated.
>
> If this API is missing, please introduce it. But not in one big patch
> instead split it into:
>
> - introduce I2C_M_RD_NEED_STOP_BIT
>
> - support flag I2C_M_RD_NEED_STOP_BIT in driver drivers/i2c/mxc_i2c.c
>
>or may we need a more common approach to this?
>
> - pcf2127 driver changes
>
> Also, as Lukasz mentioned, provide commit messages with more
> information, what you do and why.
Verbose commit messages help with understanding the _real_ problem
being solved by the patch. Also are helpful in the future as a
documentation and reference.
>
> >>
>
> >> How the error is reproduced? What are the symptoms of it?
> > You can use the i2c command to read the register data of
> > pcf2127.
>
> So the problem is with using "i2c ..." commands from U-Boot
> prompt?
> >>> Yes,but adding debugging to the rtc driver is also the same
> >>> problem
>
> > You will find that you want to read the address 0 of the
> > register, but the data of the 1 address is read, and the data
> > read later will be offset.
>
> As fair as I can tell the pcf2127 has its own DM aware driver at
> driver/rtc/pcf2127.c.
>
> Is this driver broken so you need to modify the generic i.MX I2C
> code? Have you tried to test this driver on your setup?
> >>> Pcf2127 driver also has problems, has been modified, need i2c
> >>> general code to support
> >>
> >> Just one remark the mxc_i2c.c is IMX specific I2C code. Not the
> >> generic one.
> > ok
> >>
> >> Moreover, it looks like the same approach (first send, then read)
> >> is performed in the pcf2127 driver at pcf2127_rtc_get() function.
> >>
> >> I think that the driver shall be first thoroughly checked, then
> >> fixes shall
Re: [U-Boot] [PATCH 1/2] mips: mt76xx: Implement new d-cache fix in last_stage_init()
On 22.05.19 17:58, Daniel Schwierzeck wrote:
Am 20.05.19 um 17:22 schrieb Stefan Roese:
With commit 06985289d452 ("watchdog: Implement generic watchdog_reset()
version") the init sequence has changed in arch_misc_init(), resulting
in a re-appearance of the d-cache issue on MT7688 boards (e.g. gardena).
When this happens, the first (or sometimes later ones as well) TFTP
command hangs and does not complete correctly. This leads to the
assumption that the d-cache is not in a clean state once the ethernet
driver is called (d-cache is used here for the buffers). The old work-
around with the cache flush somehow does not work any more now with
the new code change.
Testing has shown, that copying a 64KiB area in DDR at a very late
bootup time, directly before calling into the prompt, fixes this issue.
Flushing of the complete d-cache does not seem to necessary, as this
copy alone seems to fix this problem.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
---
arch/mips/Kconfig | 2 +-
arch/mips/mach-mtmips/cpu.c | 21 -
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9cf8e9800d..e3e7945567 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -84,7 +84,7 @@ config ARCH_MTMIPS
select DM_SERIAL
imply DM_SPI
imply DM_SPI_FLASH
- select ARCH_MISC_INIT
+ select LAST_STAGE_INIT
select MIPS_TUNE_24KC
select OF_CONTROL
select ROM_EXCEPTION_VECTORS
diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c
index fcd0484a6d..7afc2c5940 100644
--- a/arch/mips/mach-mtmips/cpu.c
+++ b/arch/mips/mach-mtmips/cpu.c
@@ -69,17 +69,28 @@ int print_cpuinfo(void)
return 0;
}
-int arch_misc_init(void)
+int last_stage_init(void)
{
+ void *src, *dst;
+
+ src = malloc(SZ_64K);
+ dst = malloc(SZ_64K);
+ if (!src || !dst) {
+ printf("Can't allocate buffer for cache cleanup copy!\n");
+ return 0;
+ }
+
/*
* It has been noticed, that sometimes the d-cache is not in a
* "clean-state" when U-Boot is running on MT7688. This was
* detected when using the ethernet driver (which uses d-cache)
-* and a TFTP command does not complete. Flushing the complete
-* d-cache (again?) here seems to fix this issue.
+* and a TFTP command does not complete. Copying an area of 64KiB
+* in DDR at a very late bootup time in U-Boot, directly before
+* calling into the prompt, seems to fix this issue.
*/
- flush_dcache_range(gd->bd->bi_memstart,
- gd->bd->bi_memstart + gd->ram_size - 1);
+ memcpy(dst, src, SZ_64K);
+ free(src);
+ free(dst);
return 0;
}
have you also tried with CONFIG_SYS_MALLOC_CLEAR_ON_INIT?
Not yet (AFAIR).
This will run
a memset on the whole malloc area in mem_malloc_init(). This would also
cause a cache line update for all heap memory. May this helps too and
this ugly workaround can go away ;)
Very nice idea. Testing has shown that this also fixes the cache
startup issue on my MT7688 GARDENA board. So please drop this patch.
I'll send a v2 of this series with the appropriate Kconfig change.
Many thanks for your review and input. :)
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
On 23.05.19 06:58, Prabhakar Kushwaha wrote: drivers/ata/Kconfig| 10 + drivers/ata/Makefile |1 + drivers/ata/fsl_ahci.c | 1030 drivers/ata/fsl_sata.h |1 + 4 files changed, 1042 insertions(+) create mode 100644 drivers/ata/fsl_ahci.c Will this patch series replace the old fsl_sata.c driver? If yes, could you remove this driver as well in this series? [Peng Ma] Hi Stefan, fsl_sata.c used to Non DM sata driver for some powerpc socs. Currently We only have one board that supports dts initialization. I will remove this old driver When all of our powerpc socs support DM. I see, thanks. I just wanted to know, if this new SATA driver is a meant as a replacement for the old non-DM driver. [Peng Ma] Hi Stefan, I am so sorry to reply late, Other Non dts powerpc board need the old sata driver, so the new Sata driver does not replace the so far. Just curious: Which are the "other non dts powerpc boards"? Are there still many? Is there a plan to move them to DT as well? Or should they perhaps be dropped from mainline if not converted to DT? What's stopping the conversion here? There are too many powerpc platforms which are not migrated to DT. My suggestion will be to have sata driver supporting both. Once all PowerPC platform using this SATA driver migrated, it can be dropped. I'm fine with this. Please go ahead. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
Hi Stefan, > -Original Message- > From: Stefan Roese > Sent: Wednesday, May 15, 2019 2:53 PM > To: Peng Ma ; Prabhakar Kushwaha > ; Shengzhou Liu ; > Ruchika Gupta > Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya > ; York Sun ; > bmeng...@gmail.com; m...@marvell.com; Andy Tang ; > u-boot@lists.denx.de > Subject: Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale > powerpc socs > > On 15.05.19 11:04, Peng Ma wrote: > > > > > >> -Original Message- > >> From: Stefan Roese > >> Sent: 2019年3月27日 18:48 > >> To: Peng Ma ; Prabhakar Kushwaha > >> ; Shengzhou Liu > ; > >> Ruchika Gupta > >> Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya > >> ; York Sun ; > >> bmeng...@gmail.com; m...@marvell.com; Andy Tang > ; > >> u-boot@lists.denx.de > >> Subject: Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for > >> Freescale powerpc socs > >> > >> On 27.03.19 11:41, Peng Ma wrote: > >>> > >>> > -Original Message- > From: Stefan Roese > Sent: 2019年3月27日 18:01 > To: Peng Ma ; Prabhakar Kushwaha > ; Shengzhou Liu > >> ; > Ruchika Gupta > Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya > ; York Sun ; > bmeng...@gmail.com; m...@marvell.com; Andy Tang > >> ; > u-boot@lists.denx.de > Subject: Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for > Freescale powerpc socs > > On 27.03.19 10:23, Peng Ma wrote: > > This patch is to support Freescale sata driver with dts initialized. > > Also resolved the following problems. > > > > = WARNING == This > >> board > does > > not use CONFIG_DM_SCSI. Please update the storage controller to > > use CONFIG_DM_SCSI before the v2019.07 release. > > Failure to update by the deadline may result in board removal. > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > Signed-off-by: Peng Ma > > --- > > depends on: > > - > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp > at > chw > > >> > ork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99168data > > >> > =02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef > > >> > 3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072 > > >> > 966sdata=3Z33Z5raG%2BnbtSUpz2kPCGpefk1byOgy0%2Br3R4DUFU8% > 3Dreserved=0 > > - > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > pa > > tc > > > > >> > hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99167d > ata > > > > >> > =02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef > 3%7C686e > > > > >> > a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072966 > sdata=sr > > %2BCh4UioJw0kuhOiLhc3F6keRhIH8Wflt%2BvMJnHtsY%3Dreserve > >> d= > 0 > > > > drivers/ata/Kconfig| 10 + > > drivers/ata/Makefile |1 + > > drivers/ata/fsl_ahci.c | 1030 > > > drivers/ata/fsl_sata.h |1 + > > 4 files changed, 1042 insertions(+) > > create mode 100644 drivers/ata/fsl_ahci.c > > Will this patch series replace the old fsl_sata.c driver? If yes, > could you remove this driver as well in this series? > >>> [Peng Ma] > >>> Hi Stefan, > >>> > >>> fsl_sata.c used to Non DM sata driver for some powerpc socs. > >>> Currently We only have one board that supports dts initialization. I > >>> will remove this old driver When all of our powerpc socs support DM. > >> > >> I see, thanks. I just wanted to know, if this new SATA driver is a > >> meant as a replacement for the old non-DM driver. > > [Peng Ma] > > Hi Stefan, > > > > I am so sorry to reply late, Other Non dts powerpc board need the old > > sata driver, so the new Sata driver does not replace the so far. > > Just curious: Which are the "other non dts powerpc boards"? Are there still > many? Is there a plan to move them to DT as well? Or should they perhaps be > dropped from mainline if not converted to DT? What's stopping the conversion > here? > There are too many powerpc platforms which are not migrated to DT. My suggestion will be to have sata driver supporting both. Once all PowerPC platform using this SATA driver migrated, it can be dropped. --pk. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI driver to driver model
On Thu, May 23, 2019 at 10:22 AM Prabhakar Kushwaha wrote: > > > > -Original Message- > > From: U-Boot On Behalf Of Jagan Teki > > Sent: Thursday, May 23, 2019 10:06 AM > > To: Chuanhua Han > > Cc: U-Boot-Denx ; Jiafei Pan ; > > Jagan Teki ; Yinbo Zhu ; Ruchika > > Gupta > > Subject: Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI > > driver to driver model > > > > On Mon, May 6, 2019 at 1:38 PM Chuanhua Han > > wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Jagan Teki > > > > Sent: 2019年5月6日 15:03 > > > > To: Chuanhua Han > > > > Cc: Jagan Teki ; Wolfgang Denk ; > > > > Shengzhou Liu ; Ruchika Gupta > > > > ; U-Boot-Denx ; Jiafei > > > > Pan ; Yinbo Zhu > > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > Freescale ESPI driver to driver model > > > > > > > > Caution: EXT Email > > > > > > > > On Mon, May 6, 2019 at 12:29 PM Chuanhua Han > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Jagan Teki > > > > > > Sent: 2019年4月26日 2:07 > > > > > > To: Chuanhua Han > > > > > > Cc: Jagan Teki ; Wolfgang Denk ; > > > > > > Shengzhou Liu ; Ruchika Gupta > > > > > > ; U-Boot-Denx ; > > > > > > Jiafei Pan ; Yinbo Zhu > > > > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > > Freescale ESPI driver to driver model > > > > > > > > > > > > Caution: EXT Email > > > > > > > > > > > > On Thu, Apr 25, 2019 at 8:27 AM Chuanhua Han > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi,jagan > > > > > > > Thank you for your replay! > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Jagan Teki > > > > > > > > Sent: 2019年4月24日 14:57 > > > > > > > > To: Chuanhua Han > > > > > > > > Cc: Jagan Teki ; Wolfgang Denk > > > > > > > > ; Shengzhou Liu ; Ruchika > > > > > > > > Gupta ; U-Boot-Denx > > > > > > > > ; Jiafei Pan ; > > > > > > > > Yinbo Zhu > > > > > > > > Subject: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > > > > Freescale ESPI driver to driver model > > > > > > > > > > > > > > > > WARNING: This email was created outside of NXP. DO NOT CLICK > > > > > > > > links or attachments unless you recognize the sender and > > > > > > > > know the content is > > > > > > safe. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 23, 2019 at 4:17 PM Chuanhua Han > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Modify the Freescale ESPI driver to support the driver model. > > > > > > > > > Also resolved the following problems: > > > > > > > > > > > > > > > > > > = WARNING == > > This > > > > > > > > > board > > > > > > > > does > > > > > > > > > not use CONFIG_DM_SPI. Please update the board before > > > > > > > > > v2019.04 for no dm conversion and v2019.07 for partially dm > > converted drivers. > > > > > > > > > Failure to update can lead to driver/board removal See > > > > > > > > > doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > > > = WARNING == > > This > > > > > > > > > board > > > > > > > > does > > > > > > > > > not use CONFIG_DM_SPI_FLASH. Please update the board to > > > > > > > > > use CONFIG_SPI_FLASH before the v2019.07 release. > > > > > > > > > Failure to update by the deadline may result in board removal. > > > > > > > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Chuanhua Han > > > > > > > > > --- > > > > > > > > > depends on: > > > > > > > > > - > > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https% > > > > > > > > > 3A%2 > > > > > > > > > F%2F > > > > > > > > > patc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99439d > > > > > > > > ata > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =02%7C01%7Cchuanhua.han%40nxp.com%7Cfa6bdd7859c4411b5d8608d6c8 > > > > > > > > 8223e3%7 > > > > > > > > > > > > > > > > > > > > > > > > > > > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63691685860819371 > > > > > > > > 5sda > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ta=437CqPexTmJAzhl7wZ3lAUQVbmy%2B2NvHlurTcGTJKT0%3Dreserve > > > > > > > > d=0 > > > > > > > > > > > > > > > > > > drivers/spi/fsl_espi.c | 450 > > > > > > > > > + > > > > > > > > > 1 file changed, 316 insertions(+), 134 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/drivers/spi/fsl_espi.c > > > > > > > > > b/drivers/spi/fsl_espi.c index 7444ae1a06..6ebe57c30b > > > > > > > > > 100644 > > > > > > > > > --- a/drivers/spi/fsl_espi.c > > > > > > > > > +++ b/drivers/spi/fsl_espi.c > > > > > > > > > @@ -4,17 +4,27 @@ > > > > > > > > > * > > > > > > >
Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI driver to driver model
> -Original Message- > From: U-Boot On Behalf Of Jagan Teki > Sent: Thursday, May 23, 2019 10:06 AM > To: Chuanhua Han > Cc: U-Boot-Denx ; Jiafei Pan ; > Jagan Teki ; Yinbo Zhu ; Ruchika > Gupta > Subject: Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI > driver to driver model > > On Mon, May 6, 2019 at 1:38 PM Chuanhua Han > wrote: > > > > > > > > > -Original Message- > > > From: Jagan Teki > > > Sent: 2019年5月6日 15:03 > > > To: Chuanhua Han > > > Cc: Jagan Teki ; Wolfgang Denk ; > > > Shengzhou Liu ; Ruchika Gupta > > > ; U-Boot-Denx ; Jiafei > > > Pan ; Yinbo Zhu > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > Freescale ESPI driver to driver model > > > > > > Caution: EXT Email > > > > > > On Mon, May 6, 2019 at 12:29 PM Chuanhua Han > > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Jagan Teki > > > > > Sent: 2019年4月26日 2:07 > > > > > To: Chuanhua Han > > > > > Cc: Jagan Teki ; Wolfgang Denk ; > > > > > Shengzhou Liu ; Ruchika Gupta > > > > > ; U-Boot-Denx ; > > > > > Jiafei Pan ; Yinbo Zhu > > > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > Freescale ESPI driver to driver model > > > > > > > > > > Caution: EXT Email > > > > > > > > > > On Thu, Apr 25, 2019 at 8:27 AM Chuanhua Han > > > > > > > > wrote: > > > > > > > > > > > > Hi,jagan > > > > > > Thank you for your replay! > > > > > > > > > > > > > -Original Message- > > > > > > > From: Jagan Teki > > > > > > > Sent: 2019年4月24日 14:57 > > > > > > > To: Chuanhua Han > > > > > > > Cc: Jagan Teki ; Wolfgang Denk > > > > > > > ; Shengzhou Liu ; Ruchika > > > > > > > Gupta ; U-Boot-Denx > > > > > > > ; Jiafei Pan ; > > > > > > > Yinbo Zhu > > > > > > > Subject: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > > > Freescale ESPI driver to driver model > > > > > > > > > > > > > > WARNING: This email was created outside of NXP. DO NOT CLICK > > > > > > > links or attachments unless you recognize the sender and > > > > > > > know the content is > > > > > safe. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 23, 2019 at 4:17 PM Chuanhua Han > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Modify the Freescale ESPI driver to support the driver model. > > > > > > > > Also resolved the following problems: > > > > > > > > > > > > > > > > = WARNING == > This > > > > > > > > board > > > > > > > does > > > > > > > > not use CONFIG_DM_SPI. Please update the board before > > > > > > > > v2019.04 for no dm conversion and v2019.07 for partially dm > converted drivers. > > > > > > > > Failure to update can lead to driver/board removal See > > > > > > > > doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > = WARNING == > This > > > > > > > > board > > > > > > > does > > > > > > > > not use CONFIG_DM_SPI_FLASH. Please update the board to > > > > > > > > use CONFIG_SPI_FLASH before the v2019.07 release. > > > > > > > > Failure to update by the deadline may result in board removal. > > > > > > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Chuanhua Han > > > > > > > > --- > > > > > > > > depends on: > > > > > > > > - > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https% > > > > > > > > 3A%2 > > > > > > > > F%2F > > > > > > > > patc > > > > > > > > > > > > > > > > > > > > > > > > hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99439d > > > > > > > ata > > > > > > > > > > > > > > > > > > > > > > > > =02%7C01%7Cchuanhua.han%40nxp.com%7Cfa6bdd7859c4411b5d8608d6c8 > > > > > > > 8223e3%7 > > > > > > > > > > > > > > > > > > > > > > > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63691685860819371 > > > > > > > 5sda > > > > > > > > > > > > > > > > > > > > > > > > ta=437CqPexTmJAzhl7wZ3lAUQVbmy%2B2NvHlurTcGTJKT0%3Dreserve > > > > > > > d=0 > > > > > > > > > > > > > > > > drivers/spi/fsl_espi.c | 450 > > > > > > > > + > > > > > > > > 1 file changed, 316 insertions(+), 134 deletions(-) > > > > > > > > > > > > > > > > diff --git a/drivers/spi/fsl_espi.c > > > > > > > > b/drivers/spi/fsl_espi.c index 7444ae1a06..6ebe57c30b > > > > > > > > 100644 > > > > > > > > --- a/drivers/spi/fsl_espi.c > > > > > > > > +++ b/drivers/spi/fsl_espi.c > > > > > > > > @@ -4,17 +4,27 @@ > > > > > > > > * > > > > > > > > * Copyright 2010-2011 Freescale Semiconductor, Inc. > > > > > > > > * Author: Mingkai Hu (mingkai...@freescale.com) > > > > > > > > + *Chuanhua Han (chuanhua@nxp.com) > > > > > > > > */ > > > > > > > > > > > > > > > > #include > > > > > > > > - > > > > > > > > #include > > > > > > > > #include > > > > > > > > #include
Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI driver to driver model
On Wed, May 22, 2019 at 10:23 PM Prabhakar Kushwaha wrote: > > Dear Chuanhua, Jagan, > > > -Original Message- > > From: U-Boot On Behalf Of Chuanhua Han > > Sent: Thursday, May 9, 2019 9:03 AM > > To: Jagan Teki > > Cc: U-Boot-Denx ; Jiafei Pan ; > > Jagan Teki ; Yinbo Zhu ; Ruchika > > Gupta > > Subject: Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI > > driver to driver model > > > > > > > > > -Original Message- > > > From: Jagan Teki > > > Sent: 2019年5月6日 15:03 > > > To: Chuanhua Han > > > Cc: Jagan Teki ; Wolfgang Denk ; > > > Shengzhou Liu ; Ruchika Gupta > > > ; U-Boot-Denx ; Jiafei > > > Pan ; Yinbo Zhu > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert Freescale > > > ESPI driver to driver model > > > > > > Caution: EXT Email > > > > > > On Mon, May 6, 2019 at 12:29 PM Chuanhua Han > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Jagan Teki > > > > > Sent: 2019年4月26日 2:07 > > > > > To: Chuanhua Han > > > > > Cc: Jagan Teki ; Wolfgang Denk ; > > > > > Shengzhou Liu ; Ruchika Gupta > > > > > ; U-Boot-Denx ; > > > > > Jiafei Pan ; Yinbo Zhu > > > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > Freescale ESPI driver to driver model > > > > > > > > > > Caution: EXT Email > > > > > > > > > > On Thu, Apr 25, 2019 at 8:27 AM Chuanhua Han > > > > > > > > wrote: > > > > > > > > > > > > Hi,jagan > > > > > > Thank you for your replay! > > > > > > > > > > > > > -Original Message- > > > > > > > From: Jagan Teki > > > > > > > Sent: 2019年4月24日 14:57 > > > > > > > To: Chuanhua Han > > > > > > > Cc: Jagan Teki ; Wolfgang Denk > > > > > > > ; Shengzhou Liu ; Ruchika > > > > > > > Gupta ; U-Boot-Denx > > > > > > > ; Jiafei Pan ; Yinbo > > > > > > > Zhu > > > > > > > Subject: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > > > Freescale ESPI driver to driver model > > > > > > > > > > > > > > WARNING: This email was created outside of NXP. DO NOT CLICK > > > > > > > links or attachments unless you recognize the sender and know > > > > > > > the content is > > > > > safe. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 23, 2019 at 4:17 PM Chuanhua Han > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Modify the Freescale ESPI driver to support the driver model. > > > > > > > > Also resolved the following problems: > > > > > > > > > > > > > > > > = WARNING == This > > > > > > > > board > > > > > > > does > > > > > > > > not use CONFIG_DM_SPI. Please update the board before > > > > > > > > v2019.04 for no dm conversion and v2019.07 for partially dm > > converted drivers. > > > > > > > > Failure to update can lead to driver/board removal See > > > > > > > > doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > = WARNING == This > > > > > > > > board > > > > > > > does > > > > > > > > not use CONFIG_DM_SPI_FLASH. Please update the board to use > > > > > > > > CONFIG_SPI_FLASH before the v2019.07 release. > > > > > > > > Failure to update by the deadline may result in board removal. > > > > > > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Chuanhua Han > > > > > > > > --- > > > > > > > > depends on: > > > > > > > > - > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A > > > > > > > > %2 > > > > > > > > F%2F > > > > > > > > patc > > > > > > > > > > > > > > > > > > > > > > > hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99439d > > > > > > > ata > > > > > > > > > > > > > > > > > > > > > > > =02%7C01%7Cchuanhua.han%40nxp.com%7Cfa6bdd7859c4411b5d8608d6c8 > > > > > > > 8223e3%7 > > > > > > > > > > > > > > > > > > > > > > > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63691685860819371 > > > > > > > 5sda > > > > > > > > > > > > > > > > > > > > > > > ta=437CqPexTmJAzhl7wZ3lAUQVbmy%2B2NvHlurTcGTJKT0%3Dreserve > > > > > > > d=0 > > > > > > > > > > > > > > > > drivers/spi/fsl_espi.c | 450 > > > > > > > > + > > > > > > > > 1 file changed, 316 insertions(+), 134 deletions(-) > > > > > > > > > > > > > > > > diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c > > > > > > > > index 7444ae1a06..6ebe57c30b 100644 > > > > > > > > --- a/drivers/spi/fsl_espi.c > > > > > > > > +++ b/drivers/spi/fsl_espi.c > > > > > > > > @@ -4,17 +4,27 @@ > > > > > > > > * > > > > > > > > * Copyright 2010-2011 Freescale Semiconductor, Inc. > > > > > > > > * Author: Mingkai Hu (mingkai...@freescale.com) > > > > > > > > + *Chuanhua Han (chuanhua@nxp.com) > > > > > > > > */ > > > > > > > > > > > > > > > > #include > > > > > > > > - > > > > > > > > #include > > > > > > > > #include > > > >
Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI driver to driver model
On Mon, May 6, 2019 at 1:38 PM Chuanhua Han wrote:
>
>
>
> > -Original Message-
> > From: Jagan Teki
> > Sent: 2019年5月6日 15:03
> > To: Chuanhua Han
> > Cc: Jagan Teki ; Wolfgang Denk ;
> > Shengzhou Liu ; Ruchika Gupta
> > ; U-Boot-Denx ; Jiafei Pan
> > ; Yinbo Zhu
> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert Freescale ESPI
> > driver to driver model
> >
> > Caution: EXT Email
> >
> > On Mon, May 6, 2019 at 12:29 PM Chuanhua Han
> > wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Jagan Teki
> > > > Sent: 2019年4月26日 2:07
> > > > To: Chuanhua Han
> > > > Cc: Jagan Teki ; Wolfgang Denk ;
> > > > Shengzhou Liu ; Ruchika Gupta
> > > > ; U-Boot-Denx ; Jiafei
> > > > Pan ; Yinbo Zhu
> > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert
> > > > Freescale ESPI driver to driver model
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On Thu, Apr 25, 2019 at 8:27 AM Chuanhua Han
> >
> > > > wrote:
> > > > >
> > > > > Hi,jagan
> > > > > Thank you for your replay!
> > > > >
> > > > > > -Original Message-
> > > > > > From: Jagan Teki
> > > > > > Sent: 2019年4月24日 14:57
> > > > > > To: Chuanhua Han
> > > > > > Cc: Jagan Teki ; Wolfgang Denk ;
> > > > > > Shengzhou Liu ; Ruchika Gupta
> > > > > > ; U-Boot-Denx ;
> > > > > > Jiafei Pan ; Yinbo Zhu
> > > > > > Subject: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert
> > > > > > Freescale ESPI driver to driver model
> > > > > >
> > > > > > WARNING: This email was created outside of NXP. DO NOT CLICK
> > > > > > links or attachments unless you recognize the sender and know
> > > > > > the content is
> > > > safe.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 23, 2019 at 4:17 PM Chuanhua Han
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Modify the Freescale ESPI driver to support the driver model.
> > > > > > > Also resolved the following problems:
> > > > > > >
> > > > > > > = WARNING == This
> > > > > > > board
> > > > > > does
> > > > > > > not use CONFIG_DM_SPI. Please update the board before v2019.04
> > > > > > > for no dm conversion and v2019.07 for partially dm converted
> > > > > > > drivers.
> > > > > > > Failure to update can lead to driver/board removal See
> > > > > > > doc/driver-model/MIGRATION.txt for more info.
> > > > > > >
> > > > > > > = WARNING == This
> > > > > > > board
> > > > > > does
> > > > > > > not use CONFIG_DM_SPI_FLASH. Please update the board to use
> > > > > > > CONFIG_SPI_FLASH before the v2019.07 release.
> > > > > > > Failure to update by the deadline may result in board removal.
> > > > > > > See doc/driver-model/MIGRATION.txt for more info.
> > > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Chuanhua Han
> > > > > > > ---
> > > > > > > depends on:
> > > > > > > -
> > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2
> > > > > > > F%2F
> > > > > > > patc
> > > > > > >
> > > > > >
> > > >
> > hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99439d
> > > > > > ata
> > > > > > >
> > > > > >
> > > >
> > =02%7C01%7Cchuanhua.han%40nxp.com%7Cfa6bdd7859c4411b5d8608d6c8
> > > > > > 8223e3%7
> > > > > > >
> > > > > >
> > > >
> > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63691685860819371
> > > > > > 5sda
> > > > > > >
> > > > > >
> > > >
> > ta=437CqPexTmJAzhl7wZ3lAUQVbmy%2B2NvHlurTcGTJKT0%3Dreserve
> > > > > > d=0
> > > > > > >
> > > > > > > drivers/spi/fsl_espi.c | 450
> > > > > > > +
> > > > > > > 1 file changed, 316 insertions(+), 134 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
> > > > > > > index 7444ae1a06..6ebe57c30b 100644
> > > > > > > --- a/drivers/spi/fsl_espi.c
> > > > > > > +++ b/drivers/spi/fsl_espi.c
> > > > > > > @@ -4,17 +4,27 @@
> > > > > > > *
> > > > > > > * Copyright 2010-2011 Freescale Semiconductor, Inc.
> > > > > > > * Author: Mingkai Hu (mingkai...@freescale.com)
> > > > > > > + *Chuanhua Han (chuanhua@nxp.com)
> > > > > > > */
> > > > > > >
> > > > > > > #include
> > > > > > > -
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +
> > > > > > > +struct fsl_espi_platdata {
> > > > > > > + uint flags;
> > > > > > > + uint speed_hz;
> > > > > > > + uint num_chipselect;
> > > > > > > + fdt_addr_t regs_addr;
> > > > > > > +};
> > > > > > >
> > > > > > > -struct fsl_spi_slave {
> > > > > > > - struct spi_slave slave;
> > > > > > > +struct fsl_espi_priv {
> > > > > > > ccsr_espi_t *espi;
> > > > > > > + u32 speed_hz;
> > > > > > > unsigned intdiv16;
> > > > > > > unsigned intpm;
> > > > > >
Re: [U-Boot] [RESEND][PATCH v2] armv8: Add workaround for USB erratum A-050106
Hi Prabhakar, On Thursday, May 23, 2019 12:28, Prabhakar Kushwaha wrote: > > > > -Original Message- > > From: Prabhakar Kushwaha > > Sent: Thursday, May 23, 2019 9:20 AM > > To: Ran Wang > > Cc: York Sun ; u-boot@lists.denx.de; Albert Aribaud > > > > Subject: RE: [RESEND][PATCH v2] armv8: Add workaround for USB erratum > > A- > > 050106 > > > > Dear Ran, > > > > > -Original Message- > > > From: Ran Wang > > > Sent: Thursday, May 23, 2019 9:16 AM > > > To: Prabhakar Kushwaha > > > Cc: York Sun ; u-boot@lists.denx.de; Albert > > > Aribaud > > > Subject: RE: [RESEND][PATCH v2] armv8: Add workaround for USB > > > erratum > > > A- > > > 050106 > > > > > > Hi Prabhakar, > > > > > > On Tuesday, May 21, 2019 22:48, Prabhakar Kushwaha wrote: > > > > > > > > Dear Ran > > > > > > > > > > > > > > > > > USB3.0 Receiver needs to enable fixed equalization for each of > > > > > PHY instances in an SOC. This is similar to erratum A-009007, > > > > > but this one is for LX2160A, and the register value is different. > > > > > > > > > > Signed-off-by: Ran Wang > > > > > --- > > > > > > > > This patch is for adding workaround for errata A-050106. > > > > But you are modifying erratum_a008997(). > > > > > > > > Please avid hidden changes in a patch. > > > > I will suggest to generate 2 patches one for A-050106 and other > > > > for > > > > a008997 > > > > > > Actually the information ' @@ -139,7 +139,8 @@ static void > > > erratum_a008997(void) ' > > > automatically generated by git is not quite right, the change I made > > > is within macro PROGRAM_USB_PHY_RX_OVRD_IN_HI rather than function > > > erratum_a008997(void) . > > > You can look into the src file > > > arch/arm/cpu/armv8/fsl-layerscape/soc.c > > > for details :) > > > > > > > > > @@ -139,7 +139,8 @@ static void erratum_a008997(void) > > out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, > > USB_PHY_RX_EQ_VAL_3); \ > > out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, > > USB_PHY_RX_EQ_VAL_4) > > > > -#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) > > +#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) > || \ > > + defined(CONFIG_ARCH_LX2160A) > > > > As per my understanding this change is being done in erratum_a008997 > > Let me know, if am not seeing it correctly. > > > > Thanks for showing me. > > You are right.. this change is in between static void erratum_a008997 and your > new function Yes, looks like Git has defect on this. Thanks. Regards, Ran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND][PATCH v2] armv8: Add workaround for USB erratum A-050106
> -Original Message- > From: Prabhakar Kushwaha > Sent: Thursday, May 23, 2019 9:20 AM > To: Ran Wang > Cc: York Sun ; u-boot@lists.denx.de; Albert Aribaud > > Subject: RE: [RESEND][PATCH v2] armv8: Add workaround for USB erratum A- > 050106 > > Dear Ran, > > > -Original Message- > > From: Ran Wang > > Sent: Thursday, May 23, 2019 9:16 AM > > To: Prabhakar Kushwaha > > Cc: York Sun ; u-boot@lists.denx.de; Albert Aribaud > > > > Subject: RE: [RESEND][PATCH v2] armv8: Add workaround for USB erratum > > A- > > 050106 > > > > Hi Prabhakar, > > > > On Tuesday, May 21, 2019 22:48, Prabhakar Kushwaha wrote: > > > > > > Dear Ran > > > > > > > > > > > > > USB3.0 Receiver needs to enable fixed equalization for each of PHY > > > > instances in an SOC. This is similar to erratum A-009007, but this > > > > one is for LX2160A, and the register value is different. > > > > > > > > Signed-off-by: Ran Wang > > > > --- > > > > > > This patch is for adding workaround for errata A-050106. > > > But you are modifying erratum_a008997(). > > > > > > Please avid hidden changes in a patch. > > > I will suggest to generate 2 patches one for A-050106 and other for > > > a008997 > > > > Actually the information ' @@ -139,7 +139,8 @@ static void > > erratum_a008997(void) ' > > automatically generated by git is not quite right, the change I made > > is within macro PROGRAM_USB_PHY_RX_OVRD_IN_HI rather than function > > erratum_a008997(void) . > > You can look into the src file arch/arm/cpu/armv8/fsl-layerscape/soc.c > > for details :) > > > > > @@ -139,7 +139,8 @@ static void erratum_a008997(void) > out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, > USB_PHY_RX_EQ_VAL_3); \ > out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, > USB_PHY_RX_EQ_VAL_4) > > -#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) > +#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) || \ > + defined(CONFIG_ARCH_LX2160A) > > As per my understanding this change is being done in erratum_a008997 Let me > know, if am not seeing it correctly. > Thanks for showing me. You are right.. this change is in between static void erratum_a008997 and your new function --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
Hi Stefan, Do you have any questions about this patch? Plese let me know. Thanks. Best Regars, Peng >-Original Message- >From: Stefan Roese >Sent: 2019年5月15日 17:23 >To: Peng Ma ; Prabhakar Kushwaha >; Shengzhou Liu ; >Ruchika Gupta >Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya >; York Sun ; >bmeng...@gmail.com; m...@marvell.com; Andy Tang ; >u-boot@lists.denx.de >Subject: [EXT] Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale >powerpc socs > >Caution: EXT Email > >On 15.05.19 11:04, Peng Ma wrote: >> >> >>> -Original Message- >>> From: Stefan Roese >>> Sent: 2019年3月27日 18:48 >>> To: Peng Ma ; Prabhakar Kushwaha >>> ; Shengzhou Liu >; >>> Ruchika Gupta >>> Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya >>> ; York Sun ; >>> bmeng...@gmail.com; m...@marvell.com; Andy Tang >; >>> u-boot@lists.denx.de >>> Subject: Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for >>> Freescale powerpc socs >>> >>> On 27.03.19 11:41, Peng Ma wrote: > -Original Message- > From: Stefan Roese > Sent: 2019年3月27日 18:01 > To: Peng Ma ; Prabhakar Kushwaha > ; Shengzhou Liu >>> ; > Ruchika Gupta > Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya > ; York Sun ; > bmeng...@gmail.com; m...@marvell.com; Andy Tang >>> ; > u-boot@lists.denx.de > Subject: Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for > Freescale powerpc socs > > On 27.03.19 10:23, Peng Ma wrote: >> This patch is to support Freescale sata driver with dts initialized. >> Also resolved the following problems. >> >> = WARNING == This >>> board > does >> not use CONFIG_DM_SCSI. Please update the storage controller to >> use CONFIG_DM_SCSI before the v2019.07 release. >> Failure to update by the deadline may result in board removal. >> See doc/driver-model/MIGRATION.txt for more info. >> >> >> Signed-off-by: Peng Ma >> --- >> depends on: >> - > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp > at > chw > >>> >ork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99168data > >>> >=02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef > >>> >3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072 > >>> >966sdata=3Z33Z5raG%2BnbtSUpz2kPCGpefk1byOgy0%2Br3R4DUFU8% > 3Dreserved=0 >> - >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> pa >> tc >> > >>> >hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99167d > ata >> > >>> >=02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef > 3%7C686e >> > >>> >a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072966 > sdata=sr >> %2BCh4UioJw0kuhOiLhc3F6keRhIH8Wflt%2BvMJnHtsY%3Dreser >ve >>> d= > 0 >> >> drivers/ata/Kconfig| 10 + >> drivers/ata/Makefile |1 + >> drivers/ata/fsl_ahci.c | 1030 > >> drivers/ata/fsl_sata.h |1 + >> 4 files changed, 1042 insertions(+) >> create mode 100644 drivers/ata/fsl_ahci.c > > Will this patch series replace the old fsl_sata.c driver? If yes, > could you remove this driver as well in this series? [Peng Ma] Hi Stefan, fsl_sata.c used to Non DM sata driver for some powerpc socs. Currently We only have one board that supports dts initialization. I will remove this old driver When all of our powerpc socs support DM. >>> >>> I see, thanks. I just wanted to know, if this new SATA driver is a >>> meant as a replacement for the old non-DM driver. >> [Peng Ma] >> Hi Stefan, >> >> I am so sorry to reply late, Other Non dts powerpc board need the old >> sata driver, so the new Sata driver does not replace the so far. > >Just curious: Which are the "other non dts powerpc boards"? Are there still >many? Is there a plan to move them to DT as well? Or should they perhaps be >dropped from mainline if not converted to DT? What's stopping the conversion >here? > >Thanks, >Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: ls1028a: Add ecc address node for sata.
Move the ecc addr from driver to dts
Signed-off-by: Peng Ma
---
arch/arm/dts/fsl-ls1028a.dtsi |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index e6a443a..29a0858 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -272,9 +272,10 @@
sata: sata@320 {
compatible = "fsl,ls1028a-ahci";
- reg = <0x0 0x320 0x0 0x1>;
+ reg = <0x0 0x320 0x0 0x1/* ccsr sata base */
+ 0x7 0x100520 0x0 0x4>; /* ecc sata addr*/
+ reg-names = "sata-base", "ecc-addr";
interrupts = <0 133 4>;
- clocks = < 4 1>;
status = "disabled";
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v2 1/2] ARM: dts: Freescale: Add ecc addr for sata node
Hi prabhakar, >-Original Message- >From: Prabhakar Kushwaha >Sent: 2019年5月22日 20:33 >To: Peng Ma ; albert.u.b...@aribaud.net; >s...@chromium.org; Fabio Estevam ; York Sun > >Cc: Andy Tang ; Yinbo Zhu ; >michal.si...@xilinx.com; u-boot@lists.denx.de; Peng Ma > >Subject: RE: [v2 1/2] ARM: dts: Freescale: Add ecc addr for sata node > > >> -Original Message- >> From: Peng Ma >> Sent: Wednesday, April 17, 2019 1:19 PM >> To: albert.u.b...@aribaud.net; s...@chromium.org; Fabio Estevam >> ; York Sun ; Prabhakar >> Kushwaha >> Cc: Andy Tang ; Yinbo Zhu ; >> michal.si...@xilinx.com; u-boot@lists.denx.de; Peng Ma >> >> Subject: [v2 1/2] ARM: dts: Freescale: Add ecc addr for sata node >> >> Move the ecc addr from driver to dts. >> >> Signed-off-by: Peng Ma >> --- >> changed for v2: >> - Add reg-names to improve driver code. >> > >fix chechpatch warning i.e. updated subject and applied to fsl-qoriq master, >awaiting upstream > >Can you send patches for ls2088a and ls1028a also [Peng Ma] ls2088a is not need to ecc address, I will add ls1028 patch to upstream. Best Regards, Peng > >--pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4] drivers: net: mc: Report extra memory to Linux
MC firmware need to be aligned to 512M, so minimum 512MB DDR is reserved.
But MC support to work with 128MB or 256MB DDR memory also, in this
case, rest of the memory is not usable.
So reporting this extra memory to Linux through dtb memory fixup.
Signed-off-by: Meenakshi Aggarwal
---
changed for v1:
- Incorporated review comments in one board, Missed for
other boards
changed for v2:
- Incorporated review comments in all boards
changed for v3:
- Include revision history in patch
changed for v4:
- Remove macro TRUE/FALSE
---
board/freescale/ls1088a/ls1088a.c | 31 ---
board/freescale/ls2080ardb/ls2080ardb.c | 32 +---
board/freescale/lx2160a/lx2160a.c | 31 ---
drivers/net/fsl-mc/mc.c | 10 ++
include/fsl-mc/fsl_mc.h | 1 +
5 files changed, 96 insertions(+), 9 deletions(-)
diff --git a/board/freescale/ls1088a/ls1088a.c
b/board/freescale/ls1088a/ls1088a.c
index 6d11a13..db26938 100644
--- a/board/freescale/ls1088a/ls1088a.c
+++ b/board/freescale/ls1088a/ls1088a.c
@@ -738,11 +738,26 @@ void fsl_fdt_fixup_flash(void *fdt)
int ft_board_setup(void *blob, bd_t *bd)
{
int i;
- u64 base[CONFIG_NR_DRAM_BANKS];
- u64 size[CONFIG_NR_DRAM_BANKS];
+ u16 mc_memory_bank = 0;
+
+ u64 *base;
+ u64 *size;
+ u64 mc_memory_base = 0;
+ u64 mc_memory_size = 0;
+ u16 total_memory_banks;
ft_cpu_setup(blob, bd);
+ fdt_fixup_mc_ddr(_memory_base, _memory_size);
+
+ if (mc_memory_base != 0)
+ mc_memory_bank++;
+
+ total_memory_banks = CONFIG_NR_DRAM_BANKS + mc_memory_bank;
+
+ base = calloc(total_memory_banks, sizeof(u64));
+ size = calloc(total_memory_banks, sizeof(u64));
+
/* fixup DT for the two GPP DDR banks */
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
base[i] = gd->bd->bi_dram[i].start;
@@ -759,7 +774,17 @@ int ft_board_setup(void *blob, bd_t *bd)
size[1] = gd->arch.resv_ram - base[1];
#endif
- fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS);
+ if (mc_memory_base != 0) {
+ for (i = 0; i <= total_memory_banks; i++) {
+ if (base[i] == 0 && size[i] == 0) {
+ base[i] = mc_memory_base;
+ size[i] = mc_memory_size;
+ break;
+ }
+ }
+ }
+
+ fdt_fixup_memory_banks(blob, base, size, total_memory_banks);
fdt_fsl_mc_fixup_iommu_map_entry(blob);
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
b/board/freescale/ls2080ardb/ls2080ardb.c
index ce419df..318ee65 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -409,11 +409,27 @@ void fsl_fdt_fixup_flash(void *fdt)
int ft_board_setup(void *blob, bd_t *bd)
{
- u64 base[CONFIG_NR_DRAM_BANKS];
- u64 size[CONFIG_NR_DRAM_BANKS];
+ int i;
+ u16 mc_memory_bank = 0;
+
+ u64 *base;
+ u64 *size;
+ u64 mc_memory_base = 0;
+ u64 mc_memory_size = 0;
+ u16 total_memory_banks;
ft_cpu_setup(blob, bd);
+ fdt_fixup_mc_ddr(_memory_base, _memory_size);
+
+ if (mc_memory_base != 0)
+ mc_memory_bank++;
+
+ total_memory_banks = CONFIG_NR_DRAM_BANKS + mc_memory_bank;
+
+ base = calloc(total_memory_banks, sizeof(u64));
+ size = calloc(total_memory_banks, sizeof(u64));
+
/* fixup DT for the two GPP DDR banks */
base[0] = gd->bd->bi_dram[0].start;
size[0] = gd->bd->bi_dram[0].size;
@@ -430,7 +446,17 @@ int ft_board_setup(void *blob, bd_t *bd)
size[1] = gd->arch.resv_ram - base[1];
#endif
- fdt_fixup_memory_banks(blob, base, size, 2);
+ if (mc_memory_base != 0) {
+ for (i = 0; i <= total_memory_banks; i++) {
+ if (base[i] == 0 && size[i] == 0) {
+ base[i] = mc_memory_base;
+ size[i] = mc_memory_size;
+ break;
+ }
+ }
+ }
+
+ fdt_fixup_memory_banks(blob, base, size, total_memory_banks);
fdt_fsl_mc_fixup_iommu_map_entry(blob);
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index 3875d04..aa2ff74 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -520,11 +520,26 @@ void board_quiesce_devices(void)
int ft_board_setup(void *blob, bd_t *bd)
{
int i;
- u64 base[CONFIG_NR_DRAM_BANKS];
- u64 size[CONFIG_NR_DRAM_BANKS];
+ u16 mc_memory_bank = 0;
+
+ u64 *base;
+ u64 *size;
+ u64 mc_memory_base = 0;
+ u64 mc_memory_size = 0;
+ u16
Re: [U-Boot] [RESEND][PATCH v2] armv8: Add workaround for USB erratum A-050106
Dear Ran, > -Original Message- > From: Ran Wang > Sent: Thursday, May 23, 2019 9:16 AM > To: Prabhakar Kushwaha > Cc: York Sun ; u-boot@lists.denx.de; Albert Aribaud > > Subject: RE: [RESEND][PATCH v2] armv8: Add workaround for USB erratum A- > 050106 > > Hi Prabhakar, > > On Tuesday, May 21, 2019 22:48, Prabhakar Kushwaha wrote: > > > > Dear Ran > > > > > > > > > USB3.0 Receiver needs to enable fixed equalization for each of PHY > > > instances in an SOC. This is similar to erratum A-009007, but this > > > one is for LX2160A, and the register value is different. > > > > > > Signed-off-by: Ran Wang > > > --- > > > > This patch is for adding workaround for errata A-050106. > > But you are modifying erratum_a008997(). > > > > Please avid hidden changes in a patch. > > I will suggest to generate 2 patches one for A-050106 and other for > > a008997 > > Actually the information ' @@ -139,7 +139,8 @@ static void > erratum_a008997(void) ' > automatically generated by git is not quite right, the change I made is within > macro PROGRAM_USB_PHY_RX_OVRD_IN_HI rather than function > erratum_a008997(void) . > You can look into the src file arch/arm/cpu/armv8/fsl-layerscape/soc.c for > details :) > @@ -139,7 +139,8 @@ static void erratum_a008997(void) out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_3); \ out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_4) -#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) +#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) || \ + defined(CONFIG_ARCH_LX2160A) As per my understanding this change is being done in erratum_a008997 Let me know, if am not seeing it correctly. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] drivers: net: mc: Report extra memory to Linux
> -Original Message-
> From: Meenakshi Aggarwal
> Sent: Thursday, May 23, 2019 2:33 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
>
> Cc: Meenakshi Aggarwal
> Subject: [PATCH v3] drivers: net: mc: Report extra memory to Linux
>
> MC firmware need to be aligned to 512M, so minimum 512MB DDR is reserved.
> But MC support to work with 128MB or 256MB DDR memory also, in this case,
> rest of the memory is not usable.
> So reporting this extra memory to Linux through dtb memory fixup.
>
> Signed-off-by: Meenakshi Aggarwal
> ---
> changed for v1:
> - Incorporated review comments in one board, Missed for
> other boards
> changed for v2:
> - Incorporated review comments in all boards changed for v3:
> - Include revision history in patch
> ---
> board/freescale/ls1088a/ls1088a.c | 34
> +---
> board/freescale/ls2080ardb/ls2080ardb.c | 35
> ++---
> board/freescale/lx2160a/lx2160a.c | 34
> +---
> drivers/net/fsl-mc/mc.c | 10 ++
> include/fsl-mc/fsl_mc.h | 1 +
> 5 files changed, 105 insertions(+), 9 deletions(-)
>
> diff --git a/board/freescale/ls1088a/ls1088a.c
> b/board/freescale/ls1088a/ls1088a.c
> index 6d11a13..88c34cb 100644
> --- a/board/freescale/ls1088a/ls1088a.c
> +++ b/board/freescale/ls1088a/ls1088a.c
> @@ -28,6 +28,9 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#define TRUE 1
> +#define FALSE0
> +
> #ifdef CONFIG_TARGET_LS1088AQDS
> #ifdef CONFIG_TFABOOT
> struct ifc_regs ifc_cfg_ifc_nor_boot[CONFIG_SYS_FSL_IFC_BANK_COUNT] = {
> @@ -738,11 +741,26 @@ void fsl_fdt_fixup_flash(void *fdt) int
> ft_board_setup(void *blob, bd_t *bd) {
> int i;
> - u64 base[CONFIG_NR_DRAM_BANKS];
> - u64 size[CONFIG_NR_DRAM_BANKS];
> + bool mc_memory_bank = FALSE;
> +
Use at u8 or u16 or u32. Don't use as bool
> + u64 *base;
> + u64 *size;
> + u64 mc_memory_base = 0;
> + u64 mc_memory_size = 0;
> + u16 total_memory_banks;
>
> ft_cpu_setup(blob, bd);
>
> + fdt_fixup_mc_ddr(_memory_base, _memory_size);
> +
> + if (mc_memory_base != 0)
> + mc_memory_bank = TRUE;
> +
Please avoid TRUE and FALSE for increment.
Directly do mc_memory_bank++
--pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND][PATCH v2] armv8: Add workaround for USB erratum A-050106
Hi Prabhakar, On Tuesday, May 21, 2019 22:48, Prabhakar Kushwaha wrote: > > Dear Ran > > > > > USB3.0 Receiver needs to enable fixed equalization for each of PHY > > instances in an SOC. This is similar to erratum A-009007, but this one > > is for LX2160A, and the register value is different. > > > > Signed-off-by: Ran Wang > > --- > > This patch is for adding workaround for errata A-050106. > But you are modifying erratum_a008997(). > > Please avid hidden changes in a patch. > I will suggest to generate 2 patches one for A-050106 and other for a008997 Actually the information ' @@ -139,7 +139,8 @@ static void erratum_a008997(void) ' automatically generated by git is not quite right, the change I made is within macro PROGRAM_USB_PHY_RX_OVRD_IN_HI rather than function erratum_a008997(void) . You can look into the src file arch/arm/cpu/armv8/fsl-layerscape/soc.c for details :) Regards, Ran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8: ls1028ardb: Add sd and emmc related environments
Hi Prabhakar,
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: 2019年5月23日 11:39
> To: Andy Tang
> Cc: u-boot@lists.denx.de; Andy Tang
> Subject: RE: [PATCH v2] armv8: ls1028ardb: Add sd and emmc related
> environments
>
>
> > -Original Message-
> > From: Yuantian Tang
> > Sent: Thursday, May 23, 2019 7:46 AM
> > To: Prabhakar Kushwaha
> > Cc: u-boot@lists.denx.de; Andy Tang
> > Subject: [PATCH v2] armv8: ls1028ardb: Add sd and emmc related
> environments
> >
> > Add SD, EMMC and xspi environments to faciliate the boot.
> >
> > Signed-off-by: Yuantian Tang
> > ---
> > v2:
> > - rebase to latest code
> > include/configs/ls1028a_common.h | 24 +---
> > 1 file changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/configs/ls1028a_common.h
> > b/include/configs/ls1028a_common.h
> > index 0db86396e9..9531548184 100644
> > --- a/include/configs/ls1028a_common.h
> > +++ b/include/configs/ls1028a_common.h
> > @@ -127,25 +127,43 @@
> > "${scripthdraddr} ${prefix}${boot_script_hdr} " \
> > "&& esbc_validate ${scripthdraddr};"\
> > "source ${scriptaddr}\0" \
> > - "sd_bootcmd=echo Trying load from SD ..;" \
> > + "xspi_bootcmd=echo Trying load from FlexSPI flash ...;" \
> > + "sf probe 0:0 && sf read $load_addr " \
> > + "$kernel_start $kernel_size ; env exists secureboot &&" \
> > + "sf read $kernelheader_addr_r $kernelheader_start " \
> > + "$kernelheader_size && esbc_validate ${kernelheader_addr_r};
> > "\
> > + " bootm $load_addr#$board\0" \
> > + "sd_bootcmd=echo Trying load from SD ...;" \
> > "mmcinfo; mmc read $load_addr " \
> > "$kernel_addr_sd $kernel_size_sd && " \
> > "env exists secureboot && mmc read $kernelheader_addr_r " \
> > "$kernelhdr_addr_sd $kernelhdr_size_sd "\
> > " && esbc_validate ${kernelheader_addr_r};" \
> > "bootm $load_addr#$board\0" \
> > + "xspi_hdploadcmd=echo Trying load HDP firmware from
> > FlexSPI...;" \
> > + "sf probe 0:0 && sf read $load_addr 0x94 0x3 " \
> > + "&& hdp load $load_addr 0x2000\0" \
> > + "sd_hdploadcmd=echo Trying load HDP firmware from SD..;"\
> > + "mmcinfo;mmc read $load_addr 0x4a00 0x200 " \
> > + "&& hdp load $load_addr 0x2000\0" \
>
> Hdp support is not part of upstream code -base
>
> So can we remove hdp reference from this patch
Yeah, sure. I have not noticed that.
Thanks,
Andy
>
> --pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8: ls1028ardb: Add sd and emmc related environments
> -Original Message-
> From: Yuantian Tang
> Sent: Thursday, May 23, 2019 7:46 AM
> To: Prabhakar Kushwaha
> Cc: u-boot@lists.denx.de; Andy Tang
> Subject: [PATCH v2] armv8: ls1028ardb: Add sd and emmc related environments
>
> Add SD, EMMC and xspi environments to faciliate the boot.
>
> Signed-off-by: Yuantian Tang
> ---
> v2:
> - rebase to latest code
> include/configs/ls1028a_common.h | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/ls1028a_common.h
> b/include/configs/ls1028a_common.h
> index 0db86396e9..9531548184 100644
> --- a/include/configs/ls1028a_common.h
> +++ b/include/configs/ls1028a_common.h
> @@ -127,25 +127,43 @@
> "${scripthdraddr} ${prefix}${boot_script_hdr} " \
> "&& esbc_validate ${scripthdraddr};"\
> "source ${scriptaddr}\0" \
> - "sd_bootcmd=echo Trying load from SD ..;" \
> + "xspi_bootcmd=echo Trying load from FlexSPI flash ...;" \
> + "sf probe 0:0 && sf read $load_addr " \
> + "$kernel_start $kernel_size ; env exists secureboot &&" \
> + "sf read $kernelheader_addr_r $kernelheader_start " \
> + "$kernelheader_size && esbc_validate ${kernelheader_addr_r};
> "\
> + " bootm $load_addr#$board\0" \
> + "sd_bootcmd=echo Trying load from SD ...;" \
> "mmcinfo; mmc read $load_addr " \
> "$kernel_addr_sd $kernel_size_sd && " \
> "env exists secureboot && mmc read $kernelheader_addr_r " \
> "$kernelhdr_addr_sd $kernelhdr_size_sd "\
> " && esbc_validate ${kernelheader_addr_r};" \
> "bootm $load_addr#$board\0" \
> + "xspi_hdploadcmd=echo Trying load HDP firmware from
> FlexSPI...;" \
> + "sf probe 0:0 && sf read $load_addr 0x94 0x3 " \
> + "&& hdp load $load_addr 0x2000\0" \
> + "sd_hdploadcmd=echo Trying load HDP firmware from SD..;"\
> + "mmcinfo;mmc read $load_addr 0x4a00 0x200 " \
> + "&& hdp load $load_addr 0x2000\0" \
Hdp support is not part of upstream code -base
So can we remove hdp reference from this patch
--pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] armv8/fsl-layerscape : Add loop to check cache status
Flushing L3 cache may need variable time depending upon cache line allocation. Coming up with a proper timeout value would be best handled by simulations under multiple scenarios in your actual system. From the purely HN-F point of view, the flush would take ~15 cycles for a clean line, and ~22 cycles for a dirty line. For the dirty line case, there are many variables outside the HN-F that will increase the duration per line. For example, a *DBIDResp from the SN-F/SBSX, memory controller latency, SN-F/SBSX RetryAck responses, CCN ring congestion, CCN ring hops, etc, etc. The worst-case timeout would have to factor in all of these variables plus the HN-F cycles for every line in the L3, and assuming all lines are dirty In case if L3 is not flushed properly, system behaviour will be erratic. Add loop to check status of L3 cache, it insures that L3 is flushed properly. System will stuck in while loop if there is some issue in L3 cache flushing. Signed-off-by: Udit Kumar Signed-off-by: Meenakshi Aggarwal --- changed for v2: - An increase in timeout doesn't ensure completion of L3 cache flushing operation. So checking the L3 cache status till it succedd. --- arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index 6721a57..2ba1a51 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -414,19 +414,23 @@ ENTRY(__asm_flush_l3_dcache) mov x0, #0x1/* HNFPSTAT_SFONLY */ bl hnf_set_pstate +loop1: mov x0, #0x4/* SFONLY status */ bl hnf_pstate_poll cbz x0, 1f mov x8, #1 /* timeout */ + b loop1 1: dsb sy mov x0, #0x3/* HNFPSTAT_FAM */ bl hnf_set_pstate +loop2: mov x0, #0xc/* FAM status */ bl hnf_pstate_poll cbz x0, 1f add x8, x8, #0x2 + b loop2 1: mov x0, x8 mov lr, x29 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH] i2c: pcf2127: fix bug that read wrong time
Hello Chuanhua Han,
Am 22.05.2019 um 14:45 schrieb Chuanhua Han:
-Original Message-
From: Lukasz Majewski
Sent: 2019年5月22日 19:32
To: Chuanhua Han
Cc: h...@denx.de; u-boot@lists.denx.de; Biwen Li ;
s...@chromium.org; Stefano Babic
Subject: Re: [EXT] Re: [PATCH] i2c: pcf2127: fix bug that read wrong time
On Wed, 22 May 2019 09:31:35 +
Chuanhua Han wrote:
-Original Message-
From: Lukasz Majewski
Sent: 2019年5月22日 16:41
To: Chuanhua Han
Cc: h...@denx.de; u-boot@lists.denx.de; Biwen Li ;
s...@chromium.org; Stefano Babic
Subject: Re: [EXT] Re: [PATCH] i2c: pcf2127: fix bug that read wrong
time
Hi Chuanhua,
-Original Message-
From: Lukasz Majewski
Sent: 2019年5月22日 15:16
To: Chuanhua Han
Cc: h...@denx.de; u-boot@lists.denx.de; Biwen Li
; s...@chromium.org
Subject: [EXT] Re: [PATCH] i2c: pcf2127: fix bug that read wrong
time
Hi Chuanhua,
Because i2c driver does not generate a stop bit when reading
registers of pcf2127
The change (in the common i2c code) is rather large when
considering the description above.
Could you write a more detailed patch description? Is this only
the problem with i2c in DM?
OK, This is a problem with the i2c transport framework. After
writing the register address that you want to read, the stop
signal is missing before reading the register data.
Is the same code (as introduced in this commit) available in
Linux kernel?
The kernel does not have such a problem
Do you know maybe why such issue is not present on Linux kernel?
The kernel code is encapsulated when reading the pcf2127 register,
which separates the read and write, thus generating a stop signal
before reading the register. Eg: Here is the wrapper made by the
kernel code: static int pcf2127_i2c_read(void *context, const void
*reg, size_t reg_size, void *val, size_t val_size) {
struct device *dev = context;
struct i2c_client *client = to_i2c_client(dev);
int ret;
if (WARN_ON(reg_size != 1))
return -EINVAL;
ret = i2c_master_send(client, reg, 1);
if (ret != 1)
return ret < 0 ? ret : -EIO;
ret = i2c_master_recv(client, val, val_size);
if (ret != val_size)
return ret < 0 ? ret : -EIO;
return 0;
}
That was my point - the same shall be done in the pcf2127 driver. This is a slow
device, so we can afford for this.
There is no similar api in the uboot code to split the read data into the
address of the send register and receive the data.
Uboot encapsulates the transmit register address and the read data, so no stop
signal is generated.
If this API is missing, please introduce it. But not in one big patch
instead split it into:
- introduce I2C_M_RD_NEED_STOP_BIT
- support flag I2C_M_RD_NEED_STOP_BIT in driver drivers/i2c/mxc_i2c.c
or may we need a more common approach to this?
- pcf2127 driver changes
Also, as Lukasz mentioned, provide commit messages with more
information, what you do and why.
How the error is reproduced? What are the symptoms of it?
You can use the i2c command to read the register data of pcf2127.
So the problem is with using "i2c ..." commands from U-Boot prompt?
Yes,but adding debugging to the rtc driver is also the same problem
You will find that you want to read the address 0 of the register,
but the data of the 1 address is read, and the data read later
will be offset.
As fair as I can tell the pcf2127 has its own DM aware driver at
driver/rtc/pcf2127.c.
Is this driver broken so you need to modify the generic i.MX I2C
code? Have you tried to test this driver on your setup?
Pcf2127 driver also has problems, has been modified, need i2c general
code to support
Just one remark the mxc_i2c.c is IMX specific I2C code. Not the generic one.
ok
Moreover, it looks like the same approach (first send, then read) is performed
in the pcf2127 driver at pcf2127_rtc_get() function.
I think that the driver shall be first thoroughly checked, then fixes shall be
added to it.
I have no such device, so hard to say ... and as Lukasz alread mentioned
the driver seems to make such an approach:
52 static int pcf2127_rtc_get(struct udevice *dev, struct rtc_time *tm)
53 {
54 int ret = 0;
55 uchar buf[10] = { PCF2127_REG_CTRL1 };
56
57 ret = dm_i2c_write(dev, PCF2127_REG_CTRL1, buf, 1);
58 if (ret < 0)
59 return ret;
60 ret = dm_i2c_read(dev, PCF2127_REG_CTRL1, buf, sizeof(buf));
61 if (ret < 0)
62 return ret;
It seems there are currently no real users of this driver:
pollux:u-boot hs [master] $ grep -lr RTC_PCF2127 .
./drivers/rtc/Kconfig
./drivers/rtc/Makefile
pollux:u-boot hs [master] $
I added Meng Yi to cc, as he is the author of this driver. May he
can say here more... at last I hope, the driver worked for him.
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich,
[U-Boot] [PATCH v3] drivers: net: mc: Report extra memory to Linux
MC firmware need to be aligned to 512M, so minimum 512MB DDR is reserved.
But MC support to work with 128MB or 256MB DDR memory also, in this
case, rest of the memory is not usable.
So reporting this extra memory to Linux through dtb memory fixup.
Signed-off-by: Meenakshi Aggarwal
---
changed for v1:
- Incorporated review comments in one board, Missed for
other boards
changed for v2:
- Incorporated review comments in all boards
changed for v3:
- Include revision history in patch
---
board/freescale/ls1088a/ls1088a.c | 34 +---
board/freescale/ls2080ardb/ls2080ardb.c | 35 ++---
board/freescale/lx2160a/lx2160a.c | 34 +---
drivers/net/fsl-mc/mc.c | 10 ++
include/fsl-mc/fsl_mc.h | 1 +
5 files changed, 105 insertions(+), 9 deletions(-)
diff --git a/board/freescale/ls1088a/ls1088a.c
b/board/freescale/ls1088a/ls1088a.c
index 6d11a13..88c34cb 100644
--- a/board/freescale/ls1088a/ls1088a.c
+++ b/board/freescale/ls1088a/ls1088a.c
@@ -28,6 +28,9 @@
DECLARE_GLOBAL_DATA_PTR;
+#define TRUE 1
+#define FALSE 0
+
#ifdef CONFIG_TARGET_LS1088AQDS
#ifdef CONFIG_TFABOOT
struct ifc_regs ifc_cfg_ifc_nor_boot[CONFIG_SYS_FSL_IFC_BANK_COUNT] = {
@@ -738,11 +741,26 @@ void fsl_fdt_fixup_flash(void *fdt)
int ft_board_setup(void *blob, bd_t *bd)
{
int i;
- u64 base[CONFIG_NR_DRAM_BANKS];
- u64 size[CONFIG_NR_DRAM_BANKS];
+ bool mc_memory_bank = FALSE;
+
+ u64 *base;
+ u64 *size;
+ u64 mc_memory_base = 0;
+ u64 mc_memory_size = 0;
+ u16 total_memory_banks;
ft_cpu_setup(blob, bd);
+ fdt_fixup_mc_ddr(_memory_base, _memory_size);
+
+ if (mc_memory_base != 0)
+ mc_memory_bank = TRUE;
+
+ total_memory_banks = CONFIG_NR_DRAM_BANKS + mc_memory_bank;
+
+ base = calloc(total_memory_banks, sizeof(u64));
+ size = calloc(total_memory_banks, sizeof(u64));
+
/* fixup DT for the two GPP DDR banks */
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
base[i] = gd->bd->bi_dram[i].start;
@@ -759,7 +777,17 @@ int ft_board_setup(void *blob, bd_t *bd)
size[1] = gd->arch.resv_ram - base[1];
#endif
- fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS);
+ if (mc_memory_base != 0) {
+ for (i = 0; i <= total_memory_banks; i++) {
+ if (base[i] == 0 && size[i] == 0) {
+ base[i] = mc_memory_base;
+ size[i] = mc_memory_size;
+ break;
+ }
+ }
+ }
+
+ fdt_fixup_memory_banks(blob, base, size, total_memory_banks);
fdt_fsl_mc_fixup_iommu_map_entry(blob);
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
b/board/freescale/ls2080ardb/ls2080ardb.c
index ce419df..b6b4e80 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -22,6 +22,9 @@
#include
#include
+#define TRUE 1
+#define FALSE 0
+
#ifdef CONFIG_FSL_QIXIS
#include "../common/qixis.h"
#include "ls2080ardb_qixis.h"
@@ -409,11 +412,27 @@ void fsl_fdt_fixup_flash(void *fdt)
int ft_board_setup(void *blob, bd_t *bd)
{
- u64 base[CONFIG_NR_DRAM_BANKS];
- u64 size[CONFIG_NR_DRAM_BANKS];
+ int i;
+ bool mc_memory_bank = FALSE;
+
+ u64 *base;
+ u64 *size;
+ u64 mc_memory_base = 0;
+ u64 mc_memory_size = 0;
+ u16 total_memory_banks;
ft_cpu_setup(blob, bd);
+ fdt_fixup_mc_ddr(_memory_base, _memory_size);
+
+ if (mc_memory_base != 0)
+ mc_memory_bank = TRUE;
+
+ total_memory_banks = CONFIG_NR_DRAM_BANKS + mc_memory_bank;
+
+ base = calloc(total_memory_banks, sizeof(u64));
+ size = calloc(total_memory_banks, sizeof(u64));
+
/* fixup DT for the two GPP DDR banks */
base[0] = gd->bd->bi_dram[0].start;
size[0] = gd->bd->bi_dram[0].size;
@@ -430,7 +449,17 @@ int ft_board_setup(void *blob, bd_t *bd)
size[1] = gd->arch.resv_ram - base[1];
#endif
- fdt_fixup_memory_banks(blob, base, size, 2);
+ if (mc_memory_base != 0) {
+ for (i = 0; i <= total_memory_banks; i++) {
+ if (base[i] == 0 && size[i] == 0) {
+ base[i] = mc_memory_base;
+ size[i] = mc_memory_size;
+ break;
+ }
+ }
+ }
+
+ fdt_fixup_memory_banks(blob, base, size, total_memory_banks);
fdt_fsl_mc_fixup_iommu_map_entry(blob);
diff --git
[U-Boot] [PATCH v5 2/2] mmc: fsl_esdhc: fix probe issue without CONFIG_BLK enabled
From: Yangbo Lu
u-boot is trying to make CONFIG_BLK as a hard requirement
for DM_MMC. But now it's still not.
config BLK
bool "Support block devices"
depends on DM
default y if DM_MMC
When fsl_esdhc driver was reworked for DM_MMC support, DM_MMC
without CONFIG_BLK enabled wasn't considered. This patch is to
fix probe issue without CONFIG_BLK enabled.
Signed-off-by: Yangbo Lu
Signed-off-by: Yinbo Zhu
---
Change in v2:
Change in v3:
Remove non-TFA patch
Change in v4:
update the Copyright information
Change in v5:
Add NXP Copyright information
drivers/mmc/fsl_esdhc.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 3cdfa7f5a6..8ed1b7b553 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2007, 2010-2011 Freescale Semiconductor, Inc
+ * Copyright 2007-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2019 NXP Semiconductors
* Andy Fleming
*
* Based vaguely on the pxa mmc code:
@@ -25,6 +26,10 @@
#include
#include
+#if !CONFIG_IS_ENABLED(BLK)
+#include "mmc_private.h"
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
#define SDHCI_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
@@ -34,6 +39,7 @@ DECLARE_GLOBAL_DATA_PTR;
IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
IRQSTATEN_DINT)
#define MAX_TUNING_LOOP 40
+#define ESDHC_DRIVER_STAGE_VALUE 0x
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
@@ -1401,6 +1407,9 @@ static int fsl_esdhc_probe(struct udevice *dev)
fdt_addr_t addr;
unsigned int val;
struct mmc *mmc;
+#if !CONFIG_IS_ENABLED(BLK)
+ struct blk_desc *bdesc;
+#endif
int ret;
addr = dev_read_addr(dev);
@@ -1529,6 +1538,26 @@ static int fsl_esdhc_probe(struct udevice *dev)
mmc = >mmc;
mmc->cfg = >cfg;
mmc->dev = dev;
+#if !CONFIG_IS_ENABLED(BLK)
+ mmc->priv = priv;
+
+ /* Setup dsr related values */
+ mmc->dsr_imp = 0;
+ mmc->dsr = ESDHC_DRIVER_STAGE_VALUE;
+ /* Setup the universal parts of the block interface just once */
+ bdesc = mmc_get_blk_desc(mmc);
+ bdesc->if_type = IF_TYPE_MMC;
+ bdesc->removable = 1;
+ bdesc->devnum = mmc_get_next_devnum();
+ bdesc->block_read = mmc_bread;
+ bdesc->block_write = mmc_bwrite;
+ bdesc->block_erase = mmc_berase;
+
+ /* setup initial part type */
+ bdesc->part_type = mmc->cfg->part_type;
+ mmc_list_add(mmc);
+#endif
+
upriv->mmc = mmc;
return esdhc_init_common(priv, mmc);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/2] armv8: fsl-lsch3: add clock support for the second eSDHC
From: Yangbo Lu
Layerscape began to use two eSDHC controllers, for example,
LS1028A. They are same IP block with same reference clock.
This patch is to add clock support for the second eSDHC.
Signed-off-by: Yangbo Lu
Signed-off-by: Yinbo Zhu
---
Change in v2:
Change in v3:
Remove non-TFA patch
Change in v4:
update the Copyright information
Change in v5:
Add NXP Copyright information
arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 4 +++-
arch/arm/include/asm/arch-fsl-layerscape/clock.h| 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
index bc268e207c..2d92d267a2 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2014-2015, Freescale Semiconductor, Inc.
+ * Copyright 2014-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2019 NXP Semiconductors
*
* Derived from arch/power/cpu/mpc85xx/speed.c
*/
@@ -214,6 +215,7 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
return get_i2c_freq(0);
#if defined(CONFIG_FSL_ESDHC)
case MXC_ESDHC_CLK:
+ case MXC_ESDHC2_CLK:
return get_sdhc_freq(0);
#endif
case MXC_DSPI_CLK:
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/clock.h
b/arch/arm/include/asm/arch-fsl-layerscape/clock.h
index cf058d22a9..2f51155f21 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/clock.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/clock.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright 2015 Freescale Semiconductor, Inc.
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2019 NXP Semiconductors
*
*/
@@ -14,6 +15,7 @@ enum mxc_clock {
MXC_BUS_CLK,
MXC_UART_CLK,
MXC_ESDHC_CLK,
+ MXC_ESDHC2_CLK,
MXC_I2C_CLK,
MXC_DSPI_CLK,
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] armv8: ls1028ardb: Add sd and emmc related environments
Add SD, EMMC and xspi environments to faciliate the boot.
Signed-off-by: Yuantian Tang
---
v2:
- rebase to latest code
include/configs/ls1028a_common.h | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h
index 0db86396e9..9531548184 100644
--- a/include/configs/ls1028a_common.h
+++ b/include/configs/ls1028a_common.h
@@ -127,25 +127,43 @@
"${scripthdraddr} ${prefix}${boot_script_hdr} " \
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0" \
- "sd_bootcmd=echo Trying load from SD ..;" \
+ "xspi_bootcmd=echo Trying load from FlexSPI flash ...;" \
+ "sf probe 0:0 && sf read $load_addr " \
+ "$kernel_start $kernel_size ; env exists secureboot &&" \
+ "sf read $kernelheader_addr_r $kernelheader_start " \
+ "$kernelheader_size && esbc_validate ${kernelheader_addr_r}; "\
+ " bootm $load_addr#$board\0" \
+ "sd_bootcmd=echo Trying load from SD ...;" \
"mmcinfo; mmc read $load_addr " \
"$kernel_addr_sd $kernel_size_sd && " \
"env exists secureboot && mmc read $kernelheader_addr_r " \
"$kernelhdr_addr_sd $kernelhdr_size_sd "\
" && esbc_validate ${kernelheader_addr_r};" \
"bootm $load_addr#$board\0" \
+ "xspi_hdploadcmd=echo Trying load HDP firmware from
FlexSPI...;" \
+ "sf probe 0:0 && sf read $load_addr 0x94 0x3 " \
+ "&& hdp load $load_addr 0x2000\0" \
+ "sd_hdploadcmd=echo Trying load HDP firmware from SD..;"\
+ "mmcinfo;mmc read $load_addr 0x4a00 0x200 " \
+ "&& hdp load $load_addr 0x2000\0" \
"emmc_bootcmd=echo Trying load from EMMC ..;" \
"mmcinfo; mmc dev 1; mmc read $load_addr " \
"$kernel_addr_sd $kernel_size_sd && " \
"env exists secureboot && mmc read $kernelheader_addr_r " \
"$kernelhdr_addr_sd $kernelhdr_size_sd "\
" && esbc_validate ${kernelheader_addr_r};" \
- "bootm $load_addr#$board\0"
+ "bootm $load_addr#$board\0" \
+ "emmc_hdploadcmd=echo Trying load HDP firmware from EMMC..;" \
+ "mmc dev 1;mmcinfo;mmc read $load_addr 0x4a00 0x200 " \
+ "&& hdp load $load_addr 0x2000\0"
#undef CONFIG_BOOTCOMMAND
+#define XSPI_NOR_BOOTCOMMAND \
+ "run qspi_hdploadcmd; run distro_bootcmd; run qspi_bootcmd; " \
+ "env exists secureboot && esbc_halt;;"
#define SD_BOOTCOMMAND \
- "run distro_bootcmd;run sd_bootcmd; " \
+ "run sd_hdploadcmd; run distro_bootcmd;run sd_bootcmd; " \
"env exists secureboot && esbc_halt;"
/* Monitor Command Prompt */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ata: ahci: enable bus mastering
Hi Christian, On Thu, May 23, 2019 at 2:40 AM Simon Glass wrote: > > Hi Christian, > > On Wed, 22 May 2019 at 02:40, Christian Gmeiner > wrote: > > > > When using the coreboot target CONFIG_DM_SCSI gets set to y. This has the > > effect > > that the current 'enable bus mastering' logic gets not compiled in. This > > change > > Where is it missing? Is it because U-Boot is not scanning the PCI bus? If this is the case, we should fix similar issue on other devices, not just only SATA. > > > fixes ahci problems I am seeing on an Intel Apollolake device. > > > > Signed-off-by: Christian Gmeiner > > --- > > drivers/ata/ahci.c | 6 ++ > > 1 file changed, 6 insertions(+) > > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1028ardb: Add sd and emmc related environments
No problem. Thanks Prabhakar, BR, Andy > -Original Message- > From: Prabhakar Kushwaha > Sent: 2019年5月23日 9:11 > To: Andy Tang ; Sudhanshu Gupta > ; Harninder Rai ; > Rajesh Bhagat > Cc: u-boot@lists.denx.de; Andy Tang > Subject: RE: [PATCH] armv8: ls1028ardb: Add sd and emmc related > environments > > > > -Original Message- > > From: Prabhakar Kushwaha > > Sent: Wednesday, May 22, 2019 6:07 PM > > To: Yuantian Tang ; Sudhanshu Gupta > > ; Harninder Rai ; > > Rajesh Bhagat > > Cc: u-boot@lists.denx.de; Andy Tang > > Subject: RE: [PATCH] armv8: ls1028ardb: Add sd and emmc related > > environments > > > > > > > -Original Message- > > > From: Yuantian Tang > > > Sent: Tuesday, May 14, 2019 2:24 PM > > > To: Prabhakar Kushwaha ; Sudhanshu > Gupta > > > ; Harninder Rai ; > > > Rajesh Bhagat > > > Cc: u-boot@lists.denx.de; Andy Tang > > > Subject: [PATCH] armv8: ls1028ardb: Add sd and emmc related > > > environments > > > > > > Add SD and EMMC environments to faciliate the boot. > > > > > > Signed-off-by: Yuantian Tang > > > --- > > > > Please rebase after my pull request getting accepted > > > > My pull request accepted. Please rebase it on top of the tree. > > I am marking this patch as "change requested" > > --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1028ardb: Add sd and emmc related environments
> -Original Message- > From: Prabhakar Kushwaha > Sent: Wednesday, May 22, 2019 6:07 PM > To: Yuantian Tang ; Sudhanshu Gupta > ; Harninder Rai ; Rajesh > Bhagat > Cc: u-boot@lists.denx.de; Andy Tang > Subject: RE: [PATCH] armv8: ls1028ardb: Add sd and emmc related environments > > > > -Original Message- > > From: Yuantian Tang > > Sent: Tuesday, May 14, 2019 2:24 PM > > To: Prabhakar Kushwaha ; Sudhanshu Gupta > > ; Harninder Rai ; > > Rajesh Bhagat > > Cc: u-boot@lists.denx.de; Andy Tang > > Subject: [PATCH] armv8: ls1028ardb: Add sd and emmc related > > environments > > > > Add SD and EMMC environments to faciliate the boot. > > > > Signed-off-by: Yuantian Tang > > --- > > Please rebase after my pull request getting accepted > My pull request accepted. Please rebase it on top of the tree. I am marking this patch as "change requested" --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] remoteproc: add elf file load support
Hi Fabien,
On Wed, 22 May 2019 at 02:07, Fabien Dessenne wrote:
>
> The current implementation supports only binary file load.
> Add helpers to support ELF format (check validity, sanity check, and
> load).
> Note that since an ELF image is built for the remote processor, the load
> function uses the da_to_pa ops to translate the addresses.
>
> Signed-off-by: Loic Pallardy
> Signed-off-by: Fabien Dessenne
> ---
> drivers/remoteproc/rproc-uclass.c | 128
> ++
> include/remoteproc.h | 29 -
> 2 files changed, 156 insertions(+), 1 deletion(-)
It doesn't look like we can easily make use of the existing ELF loader.
But please add a test for this in test/dm/remoteproc.c and see below.
>
> diff --git a/drivers/remoteproc/rproc-uclass.c
> b/drivers/remoteproc/rproc-uclass.c
> index c8a41a6..ac5f9e2 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -5,6 +5,7 @@
> */
> #define pr_fmt(fmt) "%s: " fmt, __func__
> #include
> +#include
> #include
> #include
> #include
> @@ -291,6 +292,133 @@ int rproc_dev_init(int id)
> return ret;
> }
>
> +/*
> + * Determine if a valid ELF image exists at the given memory location.
> + * First look at the ELF header magic field, then make sure that it is
> + * executable.
> + */
> +bool rproc_elf_is_valid(unsigned long addr, int size)
> +{
> + Elf32_Ehdr *ehdr; /* Elf header structure pointer */
> +
> + ehdr = (Elf32_Ehdr *)addr;
> +
> + if (!IS_ELF(*ehdr) || size <= sizeof(Elf32_Ehdr)) {
> + pr_err("No elf image at address 0x%08lx\n", addr);
> + return false;
> + }
> +
> + if (ehdr->e_type != ET_EXEC) {
> + pr_err("Not a 32-bit elf image at address 0x%08lx\n", addr);
> + return false;
> + }
> +
> + return true;
> +}
> +
> +/* Basic function to verify ELF image format */
> +int rproc_elf_sanity_check(ulong addr, ulong size)
> +{
> + Elf32_Ehdr *ehdr;
> + char class;
> +
> + if (!addr) {
> + pr_err("Invalid fw address?\n");
> + return -EINVAL;
EFAULT ?
> + }
> +
> + if (size < sizeof(Elf32_Ehdr)) {
> + pr_err("Image is too small\n");
> + return -EINVAL;
ENOSPC?
> + }
> +
> + ehdr = (Elf32_Ehdr *)addr;
> +
> + /* We only support ELF32 at this point */
> + class = ehdr->e_ident[EI_CLASS];
> + if (class != ELFCLASS32) {
> + pr_err("Unsupported class: %d\n", class);
> + return -EINVAL;
EPROTONOSUPP?
> + }
> +
> + /* We assume the firmware has the same endianness as the host */
> +# ifdef __LITTLE_ENDIAN
> + if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
> +# else /* BIG ENDIAN */
> + if (ehdr->e_ident[EI_DATA] != ELFDATA2MSB) {
> +# endif
> + pr_err("Unsupported firmware endianness\n");
> + return -EINVAL;
> + }
> +
> + if (size < ehdr->e_shoff + sizeof(Elf32_Shdr)) {
> + pr_err("Image is too small\n");
> + return -EINVAL;
ESPC
> + }
> +
> + if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
> + pr_err("Image is corrupted (bad magic)\n");
> + return -EINVAL;
EBADF
> + }
> +
> + if (ehdr->e_phnum == 0) {
> + pr_err("No loadable segments\n");
> + return -EINVAL;
> + }
> +
> + if (ehdr->e_phoff > size) {
> + pr_err("Firmware size is too small\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
They are just suggestions, but please try to return useful numbers. In
general it should be possible to see what went wrong without needing
to output text.
> +/* A very simple elf loader, assumes the image is valid */
> +int rproc_elf_load_image(struct udevice *dev, unsigned long addr)
> +{
> + Elf32_Ehdr *ehdr; /* Elf header structure pointer */
> + Elf32_Phdr *phdr; /* Program header structure pointer */
> + const struct dm_rproc_ops *ops;
> + unsigned int i;
> +
> + ehdr = (Elf32_Ehdr *)addr;
> + phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
> +
> + ops = rproc_get_ops(dev);
> + if (!ops) {
> + dev_dbg(dev, "Driver has no ops?\n");
> + return -EINVAL;
> + }
This is not allowed, so you don't need to check for it.
> +
> + /* Load each program header */
> + for (i = 0; i < ehdr->e_phnum; ++i) {
> + void *dst = (void *)(uintptr_t)phdr->p_paddr;
> + void *src = (void *)addr + phdr->p_offset;
> +
> + if (phdr->p_type != PT_LOAD)
> + continue;
> +
> + if (ops->da_to_pa)
> + dst = (void *)ops->da_to_pa(dev, (ulong)dst);
> +
> + dev_dbg(dev, "Loading phdr %i to 0x%p (%i bytes)\n",
> +
Re: [U-Boot] [PATCH 2/7] dm: core: Introduce xxx_translate_dma_address()
Hi Fabien, On Wed, 22 May 2019 at 02:07, Fabien Dessenne wrote: > > Add the following functions to translate DMA address to CPU address: > - dev_translate_dma_address() > - ofnode_translate_dma_address() > - of_translate_dma_address() > These functions work the same way as xxx_translate_address(), with the > difference that the translation relies on the "dma-ranges" property > instead of the "ranges" property. > Looks good, but again, needs a test. > Signed-off-by: Fabien Dessenne > --- > drivers/core/of_addr.c | 4 > drivers/core/ofnode.c | 8 > drivers/core/read.c| 5 + > include/dm/of_addr.h | 18 ++ > include/dm/ofnode.h| 16 +++- > include/dm/read.h | 20 +++- > 6 files changed, 69 insertions(+), 2 deletions(-) > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] remoteproc: add da_to_pa ops
Hi Fabien,
On Wed, 22 May 2019 at 02:07, Fabien Dessenne wrote:
>
> This patch introduces da_to_pa function to allow translation
> between device address (remote processor view) and physical
> address (main processor view).
>
> Signed-off-by: Loic Pallardy
> Signed-off-by: Fabien Dessenne
> ---
> include/remoteproc.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index a59dba8..58df11a 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -63,6 +63,8 @@ struct dm_rproc_uclass_pdata {
> * Return 0 on success, 1 if not running, -ve on others errors
> * @ping: Ping the remote device for basic communication check(optional)
> * Return 0 on success, 1 if not responding, -ve on other errors
> + * @da_to_pa: Return translated physical address (device address different
> + * from physical address)
How about device_addr_to_phys()?
Also please add a full function comment here and below. This uclass
header seems to be delinquent.
> */
> struct dm_rproc_ops {
> int (*init)(struct udevice *dev);
> @@ -72,6 +74,7 @@ struct dm_rproc_ops {
> int (*reset)(struct udevice *dev);
> int (*is_running)(struct udevice *dev);
> int (*ping)(struct udevice *dev);
> + ulong (*da_to_pa)(struct udevice *dev, ulong da);
> };
>
> /* Accessor */
> --
> 2.7.4
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] fdt: Introduce fdt_translate_dma_address()
Hi Fabien, On Wed, 22 May 2019 at 02:07, Fabien Dessenne wrote: > > Add the fdt_translate_dma_address() function to translate DMA address to > CPU address. > This function works the same way as fdt_translate_address(), with the > difference that the translation relies on the "dma-ranges" property > instead of the "ranges" property. > > Signed-off-by: Fabien Dessenne > --- > common/fdt_support.c | 6 ++ > include/fdt_support.h | 2 ++ > 2 files changed, 8 insertions(+) Please can you add a simple test for this, and also a function comment in the header file? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] board_f: Add mach specific DMA address check function.
Hi Heiko, On Wed, 22 May 2019 at 05:29, Heiko Stuebner wrote: > > Hi Simon, > > Am Samstag, 18. Mai 2019, 18:08:58 CEST schrieb Simon Glass: > > On Tue, 7 May 2019 at 09:59, Christoph Muellner > > wrote: > > > > > > From: Christoph Müllner > > > > > > Some machines have limited DMA engines, which cannot deal > > > with arbitrary addresses. This patch introduces a function > > > to model these restrictions on a machine level. > > > > > > Signed-off-by: Christoph Müllner > > > > > > Signed-off-by: Christoph Muellner > > > > > > --- > > > > > > Changes in v2: None > > > > > > common/board_f.c | 5 + > > > include/init.h | 2 ++ > > > 2 files changed, 7 insertions(+) > > > > > > > Can we handle this with driver model somehow? How does the kernel > > handle it? > > The problem Christoph is trying to solve here is doing a mmc transfer > from mmc to the sram (not main memory), which cannot use dma. > So this exact problem doesn't happen in the kernel itself. > > But back in veyron times we had a similar dma issue with anything accessing > that area as dma hung the system, but the solution was just reserving the > memblock: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b21bcfc9fda56bac573367d18ce3e4dbf3cdedf9 > > As the commit describes, other options would've been soc-settings > also going around the kernel's driver model or limiting the dma-able > memory even more (to 2GB), so we opted to just reserve the upper 16MB > completely. OK I see. > > > > Is there a device-tree binding for the DMA node that could > > provide this information. > > I don't think so. At least in the kernel affecting the dma-mask is a > setting for the using component (mmc, gmac, whatever), so would > mean adapting every device doing dma ... and even then there wasn't > a dt-binding for something like that, which in turn would've required > to adapt every driver to set a specific per-soc dma-mask for Rockchip > compatibles - hence the "simple" reserve above was the least intrusive > option. That's odd. Are you saying that some devices can DMA from SRAM and some cannot? If the DMA is not allowed, could the DMA driver return -EPERM or similar when the attempt is made, and then the bounce buffer can be used if needed? > > > > Also, where is this function called from? > > In the theobroma u-boot it gets called from the bouncebuffer right now > > https://git.theobroma-systems.com/puma-u-boot.git/commit/?id=d68222d45b4e7f55f500f5e28722cb4304ecde96 > to check if the mmc drivers can dma directly or needs to use the > bouncebuffer for reaching something like the sram. OK ta. > > > Heiko > > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Wed, 22 May 2019 at 13:42, Simon Goldschmidt wrote: > > > > Simon Glass schrieb am Mi., 22. Mai 2019, 21:34: >> >> Hi Simon, >> >> On Wed, 22 May 2019 at 02:05, Simon Goldschmidt >> wrote: >> > >> > On Wed, May 22, 2019 at 2:53 AM Simon Glass wrote: >> > > >> > > Hi Andreas, >> > > >> > > On Tue, 21 May 2019 at 15:01, Andreas Dannenberg >> > > wrote: >> > > > >> > > > Hi Simon (Glass), >> > > > >> > > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: >> > > > > Hi Andreas, >> > > > > >> > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg >> > > > > wrote: >> > > > > > >> > > > > > Hi Simon, >> > > > > > >> > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: >> > > > > > > Hi Andreas, >> > > > > > > >> > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > Simon, >> > > > > > > > >> > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt >> > > > > > > > wrote: >> > > > > > > > > Simon Glass schrieb am Sa., 30. März >> > > > > > > > > 2019, 21:06: >> > > > > > > > > >> > > > > > > > > > Hi Simon, >> > > > > > > > > > >> > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt >> > > > > > > > > > wrote: >> > > > > > > > > > > >> > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If >> > > > > > > > > > > enabled, it >> > > > > > > > > > clears >> > > > > > > > > > > the bss before calling board_init_f() instead of >> > > > > > > > > > > clearing it before >> > > > > > > > > > calling >> > > > > > > > > > > board_init_r(). >> > > > > > > > > > > >> > > > > > > > > > > This also ensures that variables placed in BSS can be >> > > > > > > > > > > shared between >> > > > > > > > > > > board_init_f() and board_init_r() in SPL. >> > > > > > > > > > > >> > > > > > > > > > > Such global variables are used, for example, when >> > > > > > > > > > > loading things from FAT >> > > > > > > > > > > before SDRAM is available: the full heap required for >> > > > > > > > > > > FAT uses global >> > > > > > > > > > > variables and clearing BSS after board_init_f() would >> > > > > > > > > > > reset the heap >> > > > > > > > > > state. >> > > > > > > > > > > An example for such a usage is socfpa_arria10 where an >> > > > > > > > > > > FPGA configuration >> > > > > > > > > > > is required before SDRAM can be used. >> > > > > > > > > > > >> > > > > > > > > > > Make the new option depend on ARM for now until more >> > > > > > > > > > > implementations >> > > > > > > > > > follow. >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > I still have objections to this series and I think we >> > > > > > > > > > should discuss >> > > > > > > > > > other ways of solving this problem. >> > > > > > > > > > >> > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is >> > > > > > > > > > available? >> > > > > > > > > > If so, can we not use that for the configuration? What >> > > > > > > > > > various are >> > > > > > > > > > actually in BSS that are needed before board_init_r() is >> > > > > > > > > > called? Can >> > > > > > > > > > they not be in a struct created from malloc()? >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > The problem is the board needs to load an FPGA configuration >> > > > > > > > > from FAT >> > > > > > > > > before SDRAM is available. Yes, this is loaded into SRAM of >> > > > > > > > > course, but the >> > > > > > > > > whole code until that is done uses so many malloc/free >> > > > > > > > > iterations that The >> > > > > > > > > simple mall of implementation would require too much memory. >> > > > > > > > > >> > > > > > > > > And it's the full malloc state variables only that use BSS, >> > > > > > > > > not the FAT >> > > > > > > > > code. >> > > > > > > > >> > > > > > > > I've actually faced very similar issues working on our TI >> > > > > > > > AM654x "System >> > > > > > > > Firmware Loader" implementation (will post upstream soon), >> > > > > > > > where I need >> > > > > > > > to load this firmware and other files from media such as >> > > > > > > > MMC/FAT in a very >> > > > > > > > memory-constrained SPL pre-relocation environment *before* I >> > > > > > > > can bring up >> > > > > > > > DDR. >> > > > > > > > >> > > > > > > > Initially, I modified the fat.c driver to re-use memory so it >> > > > > > > > is not as >> > > > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this >> > > > > > > > solution [1] >> > > > > > > > this allowed us to get going, allowing to load multiple files >> > > > > > > > without >> > > > > > > > issues in pre-relocation SPL. >> > > > > > > >> > > > > > > That seems to point the way to a useful solution I think. We >> > > > > > > could >> > > > > > > have a struct containing allocated pointers which is private to >> > > > > > > FAT, >> > > > > > > and just allocate them the first time. >> > > > > > >> > > > > > The
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon (Glass) On Tue, May 21, 2019 at 06:53:31PM -0600, Simon Glass wrote: > > > > Not having BSS available to carry over certain state to the > > > > board_init_r() world would lead to a bunch of hacky changes across > > > > the board I'm afraid, more below. > > > > > > This is really unfortunate. > > > > > > It seems to me that we have two choises: > > > > > > 1. Hack around with board_init_f() such as to remove the distinction > > > between this and board_init_r(). > > > > > > 2. Enter board_init_r() without DRAM ready, and deal with setting it up > > > there. > > > > > > I feel that the second solution is worth exploring. We could have some > > > board-specific init in board_init_r(). We already have > > > spl_board_init() so perhaps we could have spl_early_board_init() > > > called right near the top? > > > > > > We can refactor a few of the functions in spl/spl.c so they can be > > > called from board-specific code if necessary. We could also add new > > > flags to global_data to control the behaviour of the SPL code, and the > > > board code could set these. I have an alternative solution working, that essentially makes board_init_f() more useful. I understand that this is not what you wanted to see but I wanted to throw it out here anyways so we can have another look at it. Please see attached RFC for the general concept of allowing to move BSS setup prior to board_init_f for SPL via Kconfig option. This should also allow a few folks to get rid of the "hacky" memset() calls to manually clear BSS in board_initf() and with this bring some cleanup across the board (no pun intended). Of course such solution would need to go along with comment/documentation updates that are not yet comprehended in this RFC. Background, I played with the adding a hook early into SPL's board_init_r() but as expected it was not very straightforward. One challenge for example is that gd/stack are "relocated" to DDR prior to board_init_r(), but since I don't have DDR until I can use BSS to bring up DDR, adding a hook into board_init_r() to bringup DDR I couldn't see a good way to both avoid doing and then to re-do some of that stuff usually done in crt0.S after my early board_init_r() hook has ran without making changes to crt0.S itself... I'm still thinking about it... -- Andreas Dannenberg Texas Instruments Inc >From 170ad7c668050e76dcbf566ea464f5ac90851943 Mon Sep 17 00:00:00 2001 From: Andreas Dannenberg Date: Tue, 4 Dec 2018 22:30:09 -0600 Subject: [RFC] spl: Allow performing BSS init early before board_init_f() On some platform we have sufficient memory available early on to allow setting up and using a basic BSS prior to entering board_init_f(). Doing so can for example be used to carry state over to board_init_r() without having to resort to extending U-Boot's global data structure. To support such scenarios add a Kconfig option called CONFIG_SPL_EARLY_BSS to allow moving the initialization of BSS prior to entering board_init_f(), if enabled. Note that using this option usually should go along with using CONFIG_SPL_SEPARATE_BSS and configuring BSS to be located in memory actually available prior to board_init_f(). Signed-off-by: Andreas Dannenberg --- arch/arm/lib/crt0.S | 53 ++--- common/spl/Kconfig | 10 + 2 files changed, 46 insertions(+), 17 deletions(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 30fba20e1b..c74641dcd9 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -57,6 +57,33 @@ * For more information see 'Board Initialisation Flow in README. */ +/* + * Macro for clearing BSS during SPL execution. Usually called during the + * relocation process for most boards before entering board_init_r(), but + * can also be done early before entering board_init_f() on plaforms that + * can afford it due to sufficient memory being available early. + */ + +.macro SPL_CLEAR_BSS + ldr r0, =__bss_start /* this is auto-relocated! */ + +#ifdef CONFIG_USE_ARCH_MEMSET + ldr r3, =__bss_end /* this is auto-relocated! */ + mov r1, #0x /* prepare zero to clear BSS */ + + subs r2, r3, r0 /* r2 = memset len */ + bl memset +#else + ldr r1, =__bss_end /* this is auto-relocated! */ + mov r2, #0x /* prepare zero to clear BSS */ + +clbss_l:cmp r0, r1 /* while not at end of BSS */ + strlo r2, [r0] /* clear 32-bit BSS word */ + addlo r0, r0, #4 /* move to next */ + blo clbss_l +#endif +.endm + /* * entry point of crt0 sequence */ @@ -82,6 +109,10 @@ ENTRY(_main) mov r9, r0 bl board_init_f_init_reserve +#if defined(CONFIG_SPL_EARLY_BSS) + SPL_CLEAR_BSS +#endif + mov r0, #0 bl board_init_f @@ -119,6 +150,11 @@ here: bl c_runtime_cpu_setup /* we still call old routine here */ #endif #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK) + +#if !defined(CONFIG_SPL_EARLY_BSS) + SPL_CLEAR_BSS +#endif + # ifdef CONFIG_SPL_BUILD /* Use a DRAM stack for the rest of SPL, if requested */
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Glass schrieb am Mi., 22. Mai 2019, 21:34: > Hi Simon, > > On Wed, 22 May 2019 at 02:05, Simon Goldschmidt > wrote: > > > > On Wed, May 22, 2019 at 2:53 AM Simon Glass wrote: > > > > > > Hi Andreas, > > > > > > On Tue, 21 May 2019 at 15:01, Andreas Dannenberg > wrote: > > > > > > > > Hi Simon (Glass), > > > > > > > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: > > > > > Hi Andreas, > > > > > > > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg > wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > > > > > > Hi Andreas, > > > > > > > > > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg < > dannenb...@ti.com> wrote: > > > > > > > > > > > > > > > > Simon, > > > > > > > > > > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt > wrote: > > > > > > > > > Simon Glass schrieb am Sa., 30. März > 2019, 21:06: > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. > If enabled, it > > > > > > > > > > clears > > > > > > > > > > > the bss before calling board_init_f() instead of > clearing it before > > > > > > > > > > calling > > > > > > > > > > > board_init_r(). > > > > > > > > > > > > > > > > > > > > > > This also ensures that variables placed in BSS can be > shared between > > > > > > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > > > > > > > > > > > Such global variables are used, for example, when > loading things from FAT > > > > > > > > > > > before SDRAM is available: the full heap required for > FAT uses global > > > > > > > > > > > variables and clearing BSS after board_init_f() would > reset the heap > > > > > > > > > > state. > > > > > > > > > > > An example for such a usage is socfpa_arria10 where an > FPGA configuration > > > > > > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > > > > > > > > > > > Make the new option depend on ARM for now until more > implementations > > > > > > > > > > follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have objections to this series and I think we > should discuss > > > > > > > > > > other ways of solving this problem. > > > > > > > > > > > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM > is available? > > > > > > > > > > If so, can we not use that for the configuration? What > various are > > > > > > > > > > actually in BSS that are needed before board_init_r() is > called? Can > > > > > > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > > > > > > > > > > > > > > > > The problem is the board needs to load an FPGA > configuration from FAT > > > > > > > > > before SDRAM is available. Yes, this is loaded into SRAM > of course, but the > > > > > > > > > whole code until that is done uses so many malloc/free > iterations that The > > > > > > > > > simple mall of implementation would require too much > memory. > > > > > > > > > > > > > > > > > > And it's the full malloc state variables only that use > BSS, not the FAT > > > > > > > > > code. > > > > > > > > > > > > > > > > I've actually faced very similar issues working on our TI > AM654x "System > > > > > > > > Firmware Loader" implementation (will post upstream soon), > where I need > > > > > > > > to load this firmware and other files from media such as > MMC/FAT in a very > > > > > > > > memory-constrained SPL pre-relocation environment *before* I > can bring up > > > > > > > > DDR. > > > > > > > > > > > > > > > > Initially, I modified the fat.c driver to re-use memory so > it is not as > > > > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of > this solution [1] > > > > > > > > this allowed us to get going, allowing to load multiple > files without > > > > > > > > issues in pre-relocation SPL. > > > > > > > > > > > > > > That seems to point the way to a useful solution I think. We > could > > > > > > > have a struct containing allocated pointers which is private > to FAT, > > > > > > > and just allocate them the first time. > > > > > > > > > > > > The board_init_f()-based loader solution we use extends beyond > MMC/FAT, > > > > > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > > > > > > > > > > > Background: > > > > > > On our "TI K3" devices we need to do a whole bunch of stuff > before > > > > > > DDR is up with limited memory, namely loading and installing a > firmware > > > > > > that controls the entire SoC called "System Firmware". It is > only after > > > > > > this FW is loaded from boot media and successfully started that > I can > > > > > > bring up DDR. So all this is done in SPL board_init_f(), which > as the > > > > > > last step brings up DDR. > > > > > > > > > > > > Not having BSS available
Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】
Hi Andy, On Tue, 21 May 2019 at 19:56, Andy Yan wrote: > > Hi Simon: > > Simon Glass 于2019年5月22日周三 上午8:28写道： >> >> Hi Andy, >> >> On Tue, 21 May 2019 at 00:51, Andy Yan wrote: >> > >> > Hi Simon: >> > >> > On 2019/5/20 下午11:35, Simon Glass wrote: >> > > Hi Andy, >> > > >> > > On Mon, 20 May 2019 at 00:34, Andy Yan wrote: >> > >> Hi Simon: >> > >> >> > >> On 2019/5/19 上午12:26, Simon Glass wrote: >> > >>> Hi Andy, >> > >>> >> > >>> Instead of this could you: >> > >>> >> > >>> - move ATF? >> > >> All rockchip based arm64 ATF run from the start 64KB of dram as this >> > >> will give convenient for kernel manage the memory. >> > >> >> > >> On the other hand, change the ATF load address will break the >> > >> compatibility of the exiting firmware. >> > >> >> > >>> - change the SPL load address so it is not in the way (since TPL can >> > >>> load to any address) >> > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load >> > >> address if fixed by bootrom code. >> > > I think you are creating a nightmare here. If you have to do things >> > > like this for older and smaller SoCs, OK. But it should not be used >> > > for newer ones that can do things properly. >> > >> > >> > Most rockchip based SOC sram is small, even in the future soc roadmap, >> > this situation will still exist, larger sram means more cost. >> >> I believe the RK3399 has 192KB. What is the minimum size in new chips? > > > The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without > storage drive is 28KB. > The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT > SOC has the same limitation. OK, I see. > >> >> >> > >> > As for the current spl for rockchip soc in mainline, we use a workaround >> > by reserve large space at the head of spl(see >> > CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. >> >> Yes. >> >> > >> > As for my patch, the spl relocation is disabled default, we only enable >> > it on necessary platform, so it won't hurt others . >> >> Well it adds more code and complexity. Perhaps it makes sense to add >> this, but I want to understand the need. >> >> > >> > > The bootrom has so many limitations that it just creates pain. >> > > >> > >> I know we can build mmc or other storage driver into TPL so we can use >> > >> tpl load spl on some platform that sram is big enough, but there are >> > >> also many rockchip soc has very small sram, so we tend to only do dram >> > >> initialization in tpl, and let bootrom load next stage . >> > > See above >> > > >> > For the consideration of software development, we also want to keep TPL >> > clean, only do dram initialization(as it current status), this make our >> > internal dram team work more simple, they don't need to care about other >> > modules like mmc. >> >> Yes I understand this, but the boot ROM should be provided as a >> library to call into: >> >> int mmc_read(void *addr, int start_block, int end_block) >> int spi_read(void *addr, int start_block, int end_block) >> >> Then SPL or TPL can use it without all the strange limitations we have now. >> >> Since you probably already have these functions somewhere in the boot >> ROM, you could implement this using a function table somewhere in the >> ROM with a magic number before it, so that SPL can find it. > > > The Bootrom do much more work than directly load the spl binary. It will do > somthing like checksum, look for the backup when the current image is > invalid, also including security check when secure boot is enabled. This is > why we did much work to add back_too_bootrom mechanism in mainline in 2017. Yes I understand that, but it is also quite inflexible, and creates enormous problems with bootloaders. I am not suggesting that you remove functionality. I am suggesting that you allow bootloaders to call into some of it, to reduce the problems caused by the inflexible bootrom. Regards, Simon >> >> >> > >> > >> > >>> - (in extremis) create a function which does a memmove() and a jump, >> > >>> copy it somewhere and run it (I think x86 does this) >> > > ? >> > I am not very understand about this, just a memmove may not work, we >> > need to link the code by pie, and fix the rela.dyn sections after copy. >> > see arm/relocate_64.S >> >> Well if you don't access absolute addresses (which you generally don't >> in ARM) your memmove() and jump code should be relocatable. >> >> Also I wonder what you think of Andre's solution? >> > > See my reply . Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】
Hi Andy, On Tue, 21 May 2019 at 19:43, Andy Yan wrote: > > Hi Andre: > > Andre Przywara 于2019年5月20日周一 下午11:59写道： > > > On Mon, 20 May 2019 14:34:01 +0800 > > Andy Yan wrote: > > > > Hi, > > > > > On 2019/5/19 上午12:26, Simon Glass wrote: > > > > Hi Andy, > > > > > > > > Instead of this could you: > > > > > > > > - move ATF? > > > > > > All rockchip based arm64 ATF run from the start 64KB of dram as this > > > will give convenient for kernel manage the memory. > > > > This is just BL31 of ATF, right? > > ATF recently gained PIE support for BL31 [1], so by just enabling this in > > platform.mk you will get a relocatable BL31 image, with a very minimal > > runtime linker. Worked out of the box on Allwinner for me, but YMMV. > > So you could load newer ATF builds everywhere. > > > > > This is not the root case, actually we want put ATF as close as possible to > the start of dram, this give linux kernel convenient to manage the memory. But instead of 64KB you could put it at 32KB or 128KB. It's still in the first 1MB. Linux won't care, right? > > > > > Does that help you? > > > > > On the other hand, change the ATF load address will break the > > > compatibility of the exiting firmware. > > > > I am not sure what you mean with "compatibility of existing firmware"? > > Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) > > into one image? And there would be no real mix and match, with older > > pre-compiled builds? So by changing the ATF base address and the load > > address in TPL at the same time you won't have issues? > > > > I mean older pre-compiled builds published by rockchip rkbin [1], many > projects and popular boards directly use this , for example Armbian. How to > change the base address of the pre-build binary? > [1] https://github.com/rockchip-linux/rkbin Perhaps I am misunderstanding your intent here, but mainline U-Boot should not be bound to the design decisions of old closed-source binaries. [...] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Wed, 22 May 2019 at 02:05, Simon Goldschmidt wrote: > > On Wed, May 22, 2019 at 2:53 AM Simon Glass wrote: > > > > Hi Andreas, > > > > On Tue, 21 May 2019 at 15:01, Andreas Dannenberg wrote: > > > > > > Hi Simon (Glass), > > > > > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: > > > > Hi Andreas, > > > > > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > > > > > Hi Andreas, > > > > > > > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg > > > > > > wrote: > > > > > > > > > > > > > > Simon, > > > > > > > > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > > > > > > > Simon Glass schrieb am Sa., 30. März 2019, > > > > > > > > 21:06: > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If > > > > > > > > > > enabled, it > > > > > > > > > clears > > > > > > > > > > the bss before calling board_init_f() instead of clearing > > > > > > > > > > it before > > > > > > > > > calling > > > > > > > > > > board_init_r(). > > > > > > > > > > > > > > > > > > > > This also ensures that variables placed in BSS can be > > > > > > > > > > shared between > > > > > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > > > > > > > > > Such global variables are used, for example, when loading > > > > > > > > > > things from FAT > > > > > > > > > > before SDRAM is available: the full heap required for FAT > > > > > > > > > > uses global > > > > > > > > > > variables and clearing BSS after board_init_f() would reset > > > > > > > > > > the heap > > > > > > > > > state. > > > > > > > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > > > > > > > configuration > > > > > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > > > > > > > > > Make the new option depend on ARM for now until more > > > > > > > > > > implementations > > > > > > > > > follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have objections to this series and I think we should > > > > > > > > > discuss > > > > > > > > > other ways of solving this problem. > > > > > > > > > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is > > > > > > > > > available? > > > > > > > > > If so, can we not use that for the configuration? What > > > > > > > > > various are > > > > > > > > > actually in BSS that are needed before board_init_r() is > > > > > > > > > called? Can > > > > > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > > > > > > > > > > > > > The problem is the board needs to load an FPGA configuration > > > > > > > > from FAT > > > > > > > > before SDRAM is available. Yes, this is loaded into SRAM of > > > > > > > > course, but the > > > > > > > > whole code until that is done uses so many malloc/free > > > > > > > > iterations that The > > > > > > > > simple mall of implementation would require too much memory. > > > > > > > > > > > > > > > > And it's the full malloc state variables only that use BSS, not > > > > > > > > the FAT > > > > > > > > code. > > > > > > > > > > > > > > I've actually faced very similar issues working on our TI AM654x > > > > > > > "System > > > > > > > Firmware Loader" implementation (will post upstream soon), where > > > > > > > I need > > > > > > > to load this firmware and other files from media such as MMC/FAT > > > > > > > in a very > > > > > > > memory-constrained SPL pre-relocation environment *before* I can > > > > > > > bring up > > > > > > > DDR. > > > > > > > > > > > > > > Initially, I modified the fat.c driver to re-use memory so it is > > > > > > > not as > > > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this > > > > > > > solution [1] > > > > > > > this allowed us to get going, allowing to load multiple files > > > > > > > without > > > > > > > issues in pre-relocation SPL. > > > > > > > > > > > > That seems to point the way to a useful solution I think. We could > > > > > > have a struct containing allocated pointers which is private to FAT, > > > > > > and just allocate them the first time. > > > > > > > > > > The board_init_f()-based loader solution we use extends beyond > > > > > MMC/FAT, > > > > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > > > > > > > > > Background: > > > > > On our "TI K3" devices we need to do a whole bunch of stuff before > > > > > DDR is up with limited memory, namely loading and installing a > > > > > firmware > > > > > that controls the entire SoC called "System Firmware". It is only > > > > > after > > > > > this FW is loaded from boot media and successfully started that I can > > > > >
Re: [U-Boot] [PATCH 00/14] arm: k3: arm64: Initial support Texas Instrument's J721E Platform
Tom et al., On Wed, May 22, 2019 at 01:36:53PM -0500, Lokesh Vutla wrote: > This series adds initial support for Texas Instruments' K3 architecture > based J721E SoC. This series depends on the: > - mmc series posted by Faiz: > https://www.mail-archive.com/u-boot@lists.denx.de/msg315848.html > - exclusive device series posted: > https://patchwork.ozlabs.org/project/uboot/list/?series=109163 While at it, for the J721E SoC to actually boot it is also dependent on a "System Firmware Loader" solution such as [1]. Since now the wraps are off on J721E I'm going to include J721E support in any future system firmware loader series from here on (in addition to AM654x support). [1] https://lists.denx.de/pipermail/u-boot/2019-May/thread.html#368461 -- Andreas Dannenberg Texas Instruments Inc > > Andreas Dannenberg (3): > armV7R: K3: j721e: Allow using SPL BSS pre-relocation > armV7R: K3: j721e: Unlock all applicable control MMR registers > armV7R: K3: j721e: Store boot index from ROM > > Faiz Abbas (1): > mmc: am654_sdhci: Separate J721E compatible into 8bit and 4bit > versions > > Lokesh Vutla (10): > arm: K3: j721e: Add basic support for J721E SoC definition > armV7R: K3: j721e: Add support for boot device detection > armv7R: K3: j721e: Shut down R5 core after ATF startup on A72 > board: ti: j721e: Add board support for j721e evm > dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E > arm: dts: ti: Add Support for J721E SoC > arm: dts: k3-j721e: Add initial support for common processor board > arm: dts: j721e: Add r5 specific dt support > configs: j721e_evm_r5: Add initial support > configs: j721e_evm_a72: Add initial support > > arch/arm/dts/Makefile | 2 + > .../k3-j721e-common-proc-board-u-boot.dtsi| 75 ++ > arch/arm/dts/k3-j721e-common-proc-board.dts | 64 + > arch/arm/dts/k3-j721e-main.dtsi | 231 ++ > arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 72 ++ > .../arm/dts/k3-j721e-r5-common-proc-board.dts | 138 +++ > arch/arm/dts/k3-j721e-som-p0.dtsi | 29 +++ > arch/arm/dts/k3-j721e.dtsi| 176 + > arch/arm/mach-k3/Kconfig | 13 +- > arch/arm/mach-k3/Makefile | 1 + > arch/arm/mach-k3/am6_init.c | 6 - > arch/arm/mach-k3/common.c | 6 + > arch/arm/mach-k3/include/mach/hardware.h | 4 + > .../arm/mach-k3/include/mach/j721e_hardware.h | 52 > arch/arm/mach-k3/include/mach/j721e_spl.h | 31 +++ > arch/arm/mach-k3/include/mach/spl.h | 4 + > arch/arm/mach-k3/j721e_init.c | 198 +++ > board/ti/j721e/Kconfig| 54 > board/ti/j721e/Makefile | 8 + > board/ti/j721e/evm.c | 68 ++ > configs/j721e_evm_a72_defconfig | 86 +++ > configs/j721e_evm_r5_defconfig| 85 +++ > drivers/mmc/am654_sdhci.c | 114 + > include/configs/j721e_evm.h | 102 > include/dt-bindings/pinctrl/k3.h | 3 + > 25 files changed, 1571 insertions(+), 51 deletions(-) > create mode 100644 arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi > create mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts > create mode 100644 arch/arm/dts/k3-j721e-main.dtsi > create mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi > create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board.dts > create mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi > create mode 100644 arch/arm/dts/k3-j721e.dtsi > create mode 100644 arch/arm/mach-k3/include/mach/j721e_hardware.h > create mode 100644 arch/arm/mach-k3/include/mach/j721e_spl.h > create mode 100644 arch/arm/mach-k3/j721e_init.c > create mode 100644 board/ti/j721e/Kconfig > create mode 100644 board/ti/j721e/Makefile > create mode 100644 board/ti/j721e/evm.c > create mode 100644 configs/j721e_evm_a72_defconfig > create mode 100644 configs/j721e_evm_r5_defconfig > create mode 100644 include/configs/j721e_evm.h > > -- > 2.17.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Making U-Boot smaller
On Wed, May 22, 2019 at 06:50:36PM +0200, Eugeniu Rosca wrote: > Hi Tom, > > On Wed, May 22, 2019 at 11:09:54AM -0400, Tom Rini wrote: > > On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote: > > > cc: Yamada-san > > > > > > I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which > > > would point out the culprit configs. This is hardly achievable, but > > > looks good on the paper! > > > > > > CONFIG FILE SIZE > > > -- > > > CONFIG_FEATURE_A10.7Mi 37.1% > > > CONFIG_FEATURE_B5.39Mi 18.6% > > > CONFIG_FEATURE_C4.48Mi 15.5% > > > CONFIG_FEATURE_D1.86Mi 6.4% > > > CONFIG_FEATURE_E1.67Mi 5.8% > > > CONFIG_FEATURE_F1.61Mi 5.6% > > > CONFIG_FEATURE_G 856Ki 2.9% > > > CONFIG_FEATURE_H 470Ki 1.6% > > > > > > TOTAL 28.9Mi 100.0% > > > > > > [1] https://github.com/google/bloaty > > > > This is relatively easy to do today, with buildman and a local commit to > > enable/disable CONFIG_FEATURE_A. > > Being a valid choice doesn't make it necessarily appealing, especially > with 512 [1] configurations enabled in sandbox and knowing that U-Boot > is not really randconfig-grade [2] (the latter is being improved). > > What I was alluding to is embedding the Kconfig symbol names into the > ELF objects, such that utilities like 'nm' (currently producing a nice > output of symbol sizes [3]) can also be made capable to report the exact > Kconfig symbols contributing to the size of the objects passed as input. > That would be, in my opinion, mind-blowingly useful. > > [1] grep "CONFIG.*=" .config | wc -l > 512 > > [2] https://patchwork.ozlabs.org/patch/1074420/ > > [3] nm --print-size --size-sort --radix=d ./drivers/clk/clk-uclass.o > 0421 0024 T clk_free > 0961 0027 T clk_disable > 0888 0027 T clk_enable > 0027 T clk_request > 0503 0027 T clk_set_parent > 0445 0029 T clk_get_rate > 0474 0029 T clk_set_rate Right. More numbers, and more easily readable is good. But to be clear, since we use -ffunction-sections / -fdata-sections (and the kernel doesn't normally), we get can get a lot more detail than I might have implied. It's not just that you'll see that U-Boot shrank X bytes with CONFIG_FEATURE_A disabled, it's that you'll see which functions shrank by how much. What we don't have is the link between "CONFIG_OPTION_X" and "is part of functions A/B/C". But we have a lot of information like you would get out of nm already in u-boot*.map which also includes "and we discarded these functions". -- 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] ata: ahci: enable bus mastering
Hi Christian,
On Wed, 22 May 2019 at 02:40, Christian Gmeiner
wrote:
>
> When using the coreboot target CONFIG_DM_SCSI gets set to y. This has the
> effect
> that the current 'enable bus mastering' logic gets not compiled in. This
> change
Where is it missing? Is it because U-Boot is not scanning the PCI bus?
> fixes ahci problems I am seeing on an Intel Apollolake device.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/ata/ahci.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index e3135bb75f..3f9348a8b3 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1174,6 +1174,12 @@ int ahci_probe_scsi(struct udevice *ahci_dev, ulong
> base)
> int ahci_probe_scsi_pci(struct udevice *ahci_dev)
> {
> ulong base;
> + u16 cmd;
> +
> + /* Enable bus mastering. */
Please don't put . at the end.
> + dm_pci_read_config16(ahci_dev, PCI_COMMAND, );
> + cmd |= PCI_COMMAND_MASTER;
> + dm_pci_write_config16(ahci_dev, PCI_COMMAND, cmd);
See dm_pci_clrset_config16()
>
> base = (ulong)dm_pci_map_bar(ahci_dev, PCI_BASE_ADDRESS_5,
> PCI_REGION_MEM);
> --
> 2.21.0
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields
Hi Eugeniu,
On Wed, 22 May 2019 at 01:11, Eugeniu Rosca wrote:
>
> Hi Simon,
>
> Thanks for the review. Would you please reply to my questions below?
>
> On Tue, May 21, 2019 at 06:53:29PM -0600, Simon Glass wrote:
> > Hi Eugeniu,
> >
> > On Fri, 17 May 2019 at 08:46, Eugeniu Rosca wrote:
> > >
> > >
> > > [1] https://android.googlesource.com/platform/bootable/recovery
> > > [2] https://source.android.com/devices/bootloader
> > > [3] https://patchwork.ozlabs.org/patch/746835/
> > > ("[U-Boot,5/6] Initial support for the Android Bootloader flow")
> >
> > As discussed, please add these docs somewhere in the U-Boot tree (can
> > be in a separate patch)
>
> Sure.
>
> > > + if (blk_get_device_by_str("mmc", argv[1], ) < 0)
> >
> > Error codes should be reported.
>
> > > + printf("Error: Failed to read from mmc %s:%s\n", argv[1],
> > > argv[2]);
> >
> > Add error code here.
>
> Will address.
>
> > > + switch (bcb_cmd_get(argv[0])) {
> >
> > Why have a switch() here, when you could just put the below code in
> > each function? Or put the call to this function from the main
> > do_bcb_set() function.
>
> s/do_bcb_set/do_bcb/ ?
Yes
>
> The switch() is there to tell the user that he misused specifically
> {sub}command 'bcb X'. If we just throw CMD_RET_USAGE (which means
> printing full-blown help text) on _any_ kind of command misuse , we
> don't help the user _at all_, IMHO. I would consider being user-friendly
> as the higher and more important policy. However, if you prioritize the
> code size over user experience, then I am open to rewrite the function.
> Would you please clarify which policy takes precedence between the two?
I think code size in commands is not the major priority, although we
do tend to try to keep it moderate.
Here I wasn't suggesting removing code. I was just suggesting that the
error handling could be in each specific command's function. So take
the code out of each case statement and put into the function that it
relates to.
Or continue to use the generic error handler, but call it from the
generic function. It seems like we have:
do_bcb() {
switch (cmd) {
case CMD_FRED
do_bcb_fred();
...
}
...
}
do_bcb_fred() {
check_args(CMD_FRED);
...
}
check_args(int cmd) {
switch (cmd) {
case CMD_FRED:
print error
}
}
I mean, put 'print error' inside do_bcb_fred()
or, call check_args() from do_bcb()
>
> >
> > > + str = strdup(argv[2]);
> >
> > It is OK to change the args if you like.
>
> I will try getting rid of strdup.
>
> > > + if (bcb_is_misused(argc, argv))
> > > + return CMD_RET_FAILURE;
> >
> > You should return CMD_RET_USAGE if there is a usage problem.
>
> This again connects with my previous statement on the user-experience.
> I would like to tell the user where exactly he did the mistake in using
> the 'bcb' rather than throwing a full-blown help message.
Yes this is good. See above where I tried to explain what I mean.
>
> > > + if (bcb_field_get(argv[1], , ))
> > > + return CMD_RET_FAILURE;
> > > +
> > > + print_buffer((ulong)field - (ulong), (void *)field, 1, size,
> > > 16);
> >
> > Please add newline before return
>
> Fine.
>
> > > + if (!strncmp(argv[2], "=", sizeof("="))) {
> >
> > Think about code size:
> >
> > if (*argv[2] == '=')
>
> Checking a single character will not detect the difference between
> '=' and '=anything' So, I have to validate, in addition, that the
> NULL terminator is there. But I agree with the comment in general.
Yes, understood (I would calll this 'nul', BTW)
[..]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: tmio: sdhi: Do not use auto-retuning in HS400 mode
The SDHI supports automatic correction of sampling point in
HS200/SDR104 modes. However, on R-Car Gen3, this feature is
not supported in HS400 mode.
Auto and manual correction cannot both be used in HS400 mode.
Therefore, in HS400 mode, disable auto correction and ignore
the error status.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
Cc: Peng Fan
---
drivers/mmc/renesas-sdhi.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 7c53aa221e..a36162fca6 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -265,7 +265,10 @@ static int renesas_sdhi_hs400(struct udevice *dev)
tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_CKSEL);
reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
- reg |= RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+ if (hs400)
+ reg &= ~RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+ else
+ reg |= RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
/* Execute adjust hs400 offset after setting to HS400 mode */
@@ -288,10 +291,13 @@ static unsigned int renesas_sdhi_compare_scc_data(struct
tmio_sd_priv *priv)
return tmio_sd_readl(priv, RENESAS_SDHI_SCC_SMPCMP);
}
-static int renesas_sdhi_select_tuning(struct tmio_sd_priv *priv,
+static int renesas_sdhi_select_tuning(struct udevice *dev,
unsigned int tap_num, unsigned int taps,
unsigned int smpcmp)
{
+ struct tmio_sd_priv *priv = dev_get_priv(dev);
+ struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ struct mmc *mmc = upriv->mmc;
unsigned long tap_cnt; /* counter of tuning success */
unsigned long tap_start;/* start position of tuning success */
unsigned long tap_end; /* end position of tuning success */
@@ -385,9 +391,12 @@ static int renesas_sdhi_select_tuning(struct tmio_sd_priv
*priv,
/* Set SCC */
tmio_sd_writel(priv, priv->tap_set, RENESAS_SDHI_SCC_TAPSET);
- /* Enable auto re-tuning */
+ /* Enable auto re-tuning in HS200/SDR104 modes */
reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
- reg |= RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+ if (mmc->selected_mode == MMC_HS_400)
+ reg &= ~RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+ else
+ reg |= RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
return 0;
@@ -447,7 +456,7 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint
opcode)
mdelay(1);
}
- ret = renesas_sdhi_select_tuning(priv, tap_num, taps, smpcmp);
+ ret = renesas_sdhi_select_tuning(dev, tap_num, taps, smpcmp);
out:
if (ret < 0) {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/14] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
Add pinctrl macros for J721E SoC. These macro definitions are similar to that of AM6, but adding new definitions to avoid any naming confusions in the soc dts files. Signed-off-by: Lokesh Vutla Signed-off-by: Andreas Dannenberg --- include/dt-bindings/pinctrl/k3.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h index a67521cdc4..ce0cd38f56 100644 --- a/include/dt-bindings/pinctrl/k3.h +++ b/include/dt-bindings/pinctrl/k3.h @@ -35,4 +35,7 @@ #define AM65X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) #define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) +#define J721E_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) +#define J721E_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) + #endif -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/14] arm: dts: k3-j721e: Add initial support for common processor board
Common Processor board is the baseboard that has most of the actual connectors,
power supply etc. A SOM (System on Module) is plugged on to the common
processor board and this contains the SoC, PMIC, DDR and basic highspeed
components necessary for functionality. Add initial dt support for this
common processor board.
Signed-off-by: Lokesh Vutla
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/k3-j721e-common-proc-board.dts | 64 +
arch/arm/dts/k3-j721e-som-p0.dtsi | 29 ++
3 files changed, 94 insertions(+)
create mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts
create mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0ec7bc987d..818d66a17a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -750,6 +750,7 @@ dtb-$(CONFIG_TARGET_STM32MP1) += \
stm32mp157c-ev1.dtb
dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-board.dtb
+dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-bananapi-bpi-r2.dtb \
diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts
b/arch/arm/dts/k3-j721e-common-proc-board.dts
new file mode 100644
index 00..82d260ea4b
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-j721e-som-p0.dtsi"
+
+/ {
+ chosen {
+ stdout-path = "serial2:115200n8";
+ bootargs = "console=ttyS2,115200n8
earlycon=ns16550a,mmio32,0x0280";
+ };
+};
+
+_uart0 {
+ /* Wakeup UART is used by System firmware */
+ status = "disabled";
+};
+
+_uart3 {
+ /* UART not brought out */
+ status = "disabled";
+};
+
+_uart5 {
+ /* UART not brought out */
+ status = "disabled";
+};
+
+_uart6 {
+ /* UART not brought out */
+ status = "disabled";
+};
+
+_uart7 {
+ /* UART not brought out */
+ status = "disabled";
+};
+
+_uart8 {
+ /* UART not brought out */
+ status = "disabled";
+};
+
+_uart9 {
+ /* UART not brought out */
+ status = "disabled";
+};
+
+_sdhci0 {
+ /* eMMC */
+ voltage-ranges = <1800 1800>;
+ non-removable;
+ ti,driver-strength-ohm = <50>;
+};
+
+_sdhci1 {
+ /* SD/MMC */
+ voltage-ranges = <1800 1800 3300 3300>;
+ ti,driver-strength-ohm = <50>;
+};
+
diff --git a/arch/arm/dts/k3-j721e-som-p0.dtsi
b/arch/arm/dts/k3-j721e-som-p0.dtsi
new file mode 100644
index 00..1884fc7014
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-som-p0.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-j721e.dtsi"
+
+/ {
+ memory@8000 {
+ device_type = "memory";
+ /* 4G RAM */
+ reg = <0x 0x8000 0x 0x8000>,
+ <0x0008 0x8000 0x 0x8000>;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: optee@9e80 {
+ reg = <0x00 0x9e80 0x00 0x0180>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/14] arm: dts: ti: Add Support for J721E SoC
Add initial SoC definition for J721E SoC.
Kernel dts posted here:
https://lore.kernel.org/lkml/20190522161921.20750-1...@ti.com/
Signed-off-by: Lokesh Vutla
---
arch/arm/dts/k3-j721e-main.dtsi | 231 ++
arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 72
arch/arm/dts/k3-j721e.dtsi| 176
3 files changed, 479 insertions(+)
create mode 100644 arch/arm/dts/k3-j721e-main.dtsi
create mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
create mode 100644 arch/arm/dts/k3-j721e.dtsi
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
new file mode 100644
index 00..b41b1a2c03
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -0,0 +1,231 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for J721E SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2016-2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+_main {
+ msmc_ram: sram@7000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x7000 0x0 0x80>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x7000 0x80>;
+
+ atf-sram@0 {
+ reg = <0x0 0x2>;
+ };
+ };
+
+ gic500: interrupt-controller@180 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x00 0x0180 0x00 0x1>, /* GICD */
+ <0x00 0x0190 0x00 0x10>; /* GICR */
+
+ /* vcpumntirq: virtual CPU interface maintenance interrupt */
+ interrupts = ;
+
+ gic_its: gic-its@1820 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x00 0x0182 0x00 0x1>;
+ socionext,synquacer-pre-its = <0x100 0x40>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ smmu0: smmu@3660 {
+ compatible = "arm,smmu-v3";
+ reg = <0x0 0x3660 0x0 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+;
+ interrupt-names = "eventq", "gerror";
+ #iommu-cells = <1>;
+ };
+
+ secure_proxy_main: mailbox@32c0 {
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names = "target_data", "rt", "scfg";
+ reg = <0x00 0x32c0 0x00 0x10>,
+ <0x00 0x3240 0x00 0x10>,
+ <0x00 0x3280 0x00 0x10>;
+ interrupt-names = "rx_011";
+ interrupts = ;
+ };
+
+ main_pmx0: pinmux@11c000 {
+ compatible = "pinctrl-single";
+ /* Proxy 0 addressing */
+ reg = <0x0 0x11c000 0x0 0x2b4>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ };
+
+ main_uart0: serial@280 {
+ compatible = "ti,j721e-uart", "ti,am654-uart";
+ reg = <0x00 0x0280 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = ;
+ clock-frequency = <4800>;
+ current-speed = <115200>;
+ power-domains = <_pds 146>;
+ clocks = <_clks 146 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart1: serial@281 {
+ compatible = "ti,j721e-uart", "ti,am654-uart";
+ reg = <0x00 0x0281 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = ;
+ clock-frequency = <4800>;
+ current-speed = <115200>;
+ power-domains = <_pds 278>;
+ clocks = <_clks 278 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart2: serial@282 {
+ compatible = "ti,j721e-uart", "ti,am654-uart";
+ reg = <0x00 0x0282 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = ;
+ clock-frequency = <4800>;
+ current-speed = <115200>;
+ power-domains = <_pds 279>;
+ clocks = <_clks 279 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart3: serial@283 {
+ compatible = "ti,j721e-uart", "ti,am654-uart";
+ reg = <0x00 0x0283 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = ;
+
[U-Boot] [PATCH 13/14] configs: j721e_evm_r5: Add initial support
Add initial defconfig support for J721e that runs on R5. Signed-off-by: Lokesh Vutla --- configs/j721e_evm_r5_defconfig | 85 ++ 1 file changed, 85 insertions(+) create mode 100644 configs/j721e_evm_r5_defconfig diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig new file mode 100644 index 00..3faef67047 --- /dev/null +++ b/configs/j721e_evm_r5_defconfig @@ -0,0 +1,85 @@ +CONFIG_ARM=y +CONFIG_ARCH_K3=y +CONFIG_SPL_GPIO_SUPPORT=y +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SYS_MALLOC_F_LEN=0x55000 +CONFIG_SOC_K3_J721E=y +CONFIG_TARGET_J721E_R5_EVM=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_SPL_STACK_R_ADDR=0x8200 +CONFIG_SPL_FS_FAT=y +CONFIG_SPL_LIBDISK_SUPPORT=y +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI_SUPPORT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_USE_BOOTCOMMAND=y +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_SPL_TEXT_BASE=0x41c0 +CONFIG_SPL_STACK_R=y +CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_ENV_SUPPORT=y +CONFIG_SPL_I2C_SUPPORT=y +CONFIG_SPL_DM_MAILBOX=y +CONFIG_SPL_DM_RESET=y +CONFIG_SPL_POWER_SUPPORT=y +CONFIG_SPL_POWER_DOMAIN=y +CONFIG_SPL_REMOTEPROC=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SPL_YMODEM_SUPPORT=y +CONFIG_HUSH_PARSER=y +# CONFIG_CMD_FLASH is not set +# CONFIG_CMD_SETEXPR is not set +CONFIG_DOS_PARTITION=y +CONFIG_OF_CONTROL=y +CONFIG_SPL_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-common-proc-board" +CONFIG_SPL_MULTI_DTB_FIT=y +CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y +CONFIG_DM=y +CONFIG_SPL_DM=y +CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_REGMAP=y +CONFIG_SPL_REGMAP=y +CONFIG_SPL_OF_TRANSLATE=y +CONFIG_CLK=y +CONFIG_SPL_CLK=y +CONFIG_CLK_TI_SCI=y +CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_GPIO=y +CONFIG_DA8XX_GPIO=y +CONFIG_DM_MAILBOX=y +CONFIG_K3_SEC_PROXY=y +CONFIG_MISC=y +CONFIG_FS_LOADER=y +CONFIG_DM_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_AM654=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PINCTRL=y +# CONFIG_PINCTRL_GENERIC is not set +CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_GENERIC is not set +CONFIG_PINCTRL_SINGLE=y +CONFIG_POWER_DOMAIN=y +CONFIG_TI_SCI_POWER_DOMAIN=y +CONFIG_K3_SYSTEM_CONTROLLER=y +CONFIG_REMOTEPROC_TI_K3_ARM64=y +CONFIG_DM_RESET=y +CONFIG_RESET_TI_SCI=y +CONFIG_DM_SERIAL=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_CADENCE_QSPI=y +CONFIG_SYSRESET=y +CONFIG_SPL_SYSRESET=y +CONFIG_SYSRESET_TI_SCI=y +CONFIG_TIMER=y +CONFIG_SPL_TIMER=y +CONFIG_OMAP_TIMER=y +CONFIG_FS_EXT4=y +CONFIG_FS_FAT=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
On Wed, 2019-05-22 at 11:15 -0400, Tom Rini wrote: > On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote: > > On Tue, May 21, 2019 at 11:34 PM Tom Rini wrote: > > > > > As came up in another thread, CONFIG_MMC_TINY may be more widely useable > > > and should help with space. > > > > How it can be used exactly? > > > > I tried it like this: > > > > --- a/configs/mx6sabresd_defconfig > > +++ b/configs/mx6sabresd_defconfig > > @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y > > CONFIG_SPL_LIBGENERIC_SUPPORT=y > > CONFIG_SYS_MALLOC_F_LEN=0x4000 > > CONFIG_TARGET_MX6SABRESD=y > > -CONFIG_SPL_MMC_SUPPORT=y > > CONFIG_SPL_SERIAL_SUPPORT=y > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_SPL=y > > @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y > > CONFIG_USB_ETHER_ASIX=y > > CONFIG_DM_VIDEO=y > > CONFIG_VIDEO_IPUV3=y > > +CONFIG_SPL_MMC_TINY=y > > > > , but the board does not boot: > > > > U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 > > -0300) > > SPL: Unsupported Boot Device! > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how > to configure / use it, in the other thread. > I was planning to look at this, and planned to start with a Wandboard I just happen to have on my desk. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/14] mmc: am654_sdhci: Separate J721E compatible into 8bit and 4bit versions
From: Faiz Abbas
The j721e 4 bit instances don't have a hard DLL and therefore don't need
any DLL related configurations. Split the compatibles into an 8 bit and a
4 bit one. Add a private flags field which can be used to check if the
DLL is present and don't register the set_ios_post callback for the 4 bit
compatible instances.
Also update the compatibles in k3-j721e-main.dtsi to avoid breaking boot
with the new compatibles.
Signed-off-by: Faiz Abbas
Signed-off-by: Lokesh Vutla
---
drivers/mmc/am654_sdhci.c | 114 --
1 file changed, 71 insertions(+), 43 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index cc62120718..ceb5584751 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -73,6 +73,8 @@ struct am654_sdhci_plat {
u32 otap_del_sel;
u32 trm_icp;
u32 drv_strength;
+ u32 flags;
+#define DLL_PRESENT(1 << 0)
bool dll_on;
};
@@ -163,6 +165,10 @@ const struct sdhci_ops am654_sdhci_ops = {
.set_control_reg= _sdhci_set_control_reg,
};
+const struct sdhci_ops j721e_4bit_sdhci_ops = {
+ .set_control_reg= _sdhci_set_control_reg,
+};
+
int am654_sdhci_init(struct am654_sdhci_plat *plat)
{
u32 ctl_cfg_2 = 0;
@@ -173,24 +179,28 @@ int am654_sdhci_init(struct am654_sdhci_plat *plat)
mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
regmap_update_bits(plat->base, PHY_CTRL4, mask, 0x0);
- regmap_read(plat->base, PHY_STAT1, );
- if (~val & CALDONE_MASK) {
- /* Calibrate IO lines */
- regmap_update_bits(plat->base, PHY_CTRL1, PDB_MASK, PDB_MASK);
- ret = regmap_read_poll_timeout(plat->base, PHY_STAT1, val,
- val & CALDONE_MASK, 1, 20);
- if (ret)
- return ret;
- }
+ if (plat->flags & DLL_PRESENT) {
+ regmap_read(plat->base, PHY_STAT1, );
+ if (~val & CALDONE_MASK) {
+ /* Calibrate IO lines */
+ regmap_update_bits(plat->base, PHY_CTRL1, PDB_MASK,
+ PDB_MASK);
+ ret = regmap_read_poll_timeout(plat->base, PHY_STAT1,
+ val, val & CALDONE_MASK,
+ 1, 20);
+ if (ret)
+ return ret;
+ }
- /* Configure DLL TRIM */
- mask = DLL_TRIM_ICP_MASK;
- val = plat->trm_icp << DLL_TRIM_ICP_SHIFT;
+ /* Configure DLL TRIM */
+ mask = DLL_TRIM_ICP_MASK;
+ val = plat->trm_icp << DLL_TRIM_ICP_SHIFT;
- /* Configure DLL driver strength */
- mask |= DR_TY_MASK;
- val |= plat->drv_strength << DR_TY_SHIFT;
- regmap_update_bits(plat->base, PHY_CTRL1, mask, val);
+ /* Configure DLL driver strength */
+ mask |= DR_TY_MASK;
+ val |= plat->drv_strength << DR_TY_SHIFT;
+ regmap_update_bits(plat->base, PHY_CTRL1, mask, val);
+ }
/* Enable pins by setting IO mux to 0 */
regmap_update_bits(plat->base, PHY_CTRL1, IOMUX_ENABLE_MASK, 0);
@@ -246,7 +256,7 @@ static int am654_sdhci_probe(struct udevice *dev)
AM654_SDHCI_MIN_FREQ);
if (ret)
return ret;
- host->ops = _sdhci_ops;
+ host->ops = (struct sdhci_ops *)dev_get_driver_data(dev);
host->mmc->priv = host;
upriv->mmc = host->mmc;
@@ -269,37 +279,44 @@ static int am654_sdhci_ofdata_to_platdata(struct udevice
*dev)
host->ioaddr = (void *)dev_read_addr(dev);
plat->non_removable = dev_read_bool(dev, "non-removable");
- ret = dev_read_u32(dev, "ti,trm-icp", >trm_icp);
- if (ret)
- return ret;
+ if (device_is_compatible(dev, "ti,am654-sdhci-5.1") ||
+ device_is_compatible(dev, "ti,j721e-sdhci-8bit"))
+ plat->flags |= DLL_PRESENT;
ret = dev_read_u32(dev, "ti,otap-del-sel", >otap_del_sel);
if (ret)
return ret;
- ret = dev_read_u32(dev, "ti,driver-strength-ohm", _strength);
- if (ret)
- return ret;
+ if (plat->flags & DLL_PRESENT) {
+ ret = dev_read_u32(dev, "ti,trm-icp", >trm_icp);
+ if (ret)
+ return ret;
+
+ ret = dev_read_u32(dev, "ti,driver-strength-ohm",
+ _strength);
+ if (ret)
+ return ret;
- switch (drv_strength) {
- case 50:
- plat->drv_strength = DRIVER_STRENGTH_50_OHM;
- break;
- case 33:
- plat->drv_strength = DRIVER_STRENGTH_33_OHM;
- break;
- case 66:
-
[U-Boot] [PATCH 06/14] armv7R: K3: j721e: Shut down R5 core after ATF startup on A72
Populate the release_resources_for_core_shutdown() api with
shutting down r5 cores so that it will by called just after
jumping to ATF.
Signed-off-by: Lokesh Vutla
---
arch/arm/mach-k3/j721e_init.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 211ca448aa..b20c941846 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -12,6 +12,8 @@
#include
#include
#include "common.h"
+#include
+#include
#ifdef CONFIG_SPL_BUILD
static void mmr_unlock(u32 base, u32 partition)
@@ -139,3 +141,58 @@ u32 spl_boot_device(void)
return __get_primary_bootmedia(main_devstat, wkup_devstat);
}
#endif
+
+#ifdef CONFIG_SYS_K3_SPL_ATF
+
+#define J721E_DEV_MCU_RTI0 262
+#define J721E_DEV_MCU_RTI1 263
+#define J721E_DEV_MCU_ARMSS0_CPU0 250
+#define J721E_DEV_MCU_ARMSS0_CPU1 251
+
+void release_resources_for_core_shutdown(void)
+{
+ struct ti_sci_handle *ti_sci;
+ struct ti_sci_dev_ops *dev_ops;
+ struct ti_sci_proc_ops *proc_ops;
+ int ret;
+ u32 i;
+
+ const u32 put_device_ids[] = {
+ J721E_DEV_MCU_RTI0,
+ J721E_DEV_MCU_RTI1,
+ };
+
+ ti_sci = get_ti_sci_handle();
+ dev_ops = _sci->ops.dev_ops;
+ proc_ops = _sci->ops.proc_ops;
+
+ /* Iterate through list of devices to put (shutdown) */
+ for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
+ u32 id = put_device_ids[i];
+
+ ret = dev_ops->put_device(ti_sci, id);
+ if (ret)
+ panic("Failed to put device %u (%d)\n", id, ret);
+ }
+
+ const u32 put_core_ids[] = {
+ J721E_DEV_MCU_ARMSS0_CPU1,
+ J721E_DEV_MCU_ARMSS0_CPU0, /* Handle CPU0 after CPU1 */
+ };
+
+ /* Iterate through list of cores to put (shutdown) */
+ for (i = 0; i < ARRAY_SIZE(put_core_ids); i++) {
+ u32 id = put_core_ids[i];
+
+ /*
+* Queue up the core shutdown request. Note that this call
+* needs to be followed up by an actual invocation of an WFE
+* or WFI CPU instruction.
+*/
+ ret = proc_ops->proc_shutdown_no_wait(ti_sci, id);
+ if (ret)
+ panic("Failed sending core %u shutdown message (%d)\n",
+ id, ret);
+ }
+}
+#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/14] arm: k3: arm64: Initial support Texas Instrument's J721E Platform
This series adds initial support for Texas Instruments' K3 architecture based J721E SoC. This series depends on the: - mmc series posted by Faiz: https://www.mail-archive.com/u-boot@lists.denx.de/msg315848.html - exclusive device series posted: https://patchwork.ozlabs.org/project/uboot/list/?series=109163 Andreas Dannenberg (3): armV7R: K3: j721e: Allow using SPL BSS pre-relocation armV7R: K3: j721e: Unlock all applicable control MMR registers armV7R: K3: j721e: Store boot index from ROM Faiz Abbas (1): mmc: am654_sdhci: Separate J721E compatible into 8bit and 4bit versions Lokesh Vutla (10): arm: K3: j721e: Add basic support for J721E SoC definition armV7R: K3: j721e: Add support for boot device detection armv7R: K3: j721e: Shut down R5 core after ATF startup on A72 board: ti: j721e: Add board support for j721e evm dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E arm: dts: ti: Add Support for J721E SoC arm: dts: k3-j721e: Add initial support for common processor board arm: dts: j721e: Add r5 specific dt support configs: j721e_evm_r5: Add initial support configs: j721e_evm_a72: Add initial support arch/arm/dts/Makefile | 2 + .../k3-j721e-common-proc-board-u-boot.dtsi| 75 ++ arch/arm/dts/k3-j721e-common-proc-board.dts | 64 + arch/arm/dts/k3-j721e-main.dtsi | 231 ++ arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 72 ++ .../arm/dts/k3-j721e-r5-common-proc-board.dts | 138 +++ arch/arm/dts/k3-j721e-som-p0.dtsi | 29 +++ arch/arm/dts/k3-j721e.dtsi| 176 + arch/arm/mach-k3/Kconfig | 13 +- arch/arm/mach-k3/Makefile | 1 + arch/arm/mach-k3/am6_init.c | 6 - arch/arm/mach-k3/common.c | 6 + arch/arm/mach-k3/include/mach/hardware.h | 4 + .../arm/mach-k3/include/mach/j721e_hardware.h | 52 arch/arm/mach-k3/include/mach/j721e_spl.h | 31 +++ arch/arm/mach-k3/include/mach/spl.h | 4 + arch/arm/mach-k3/j721e_init.c | 198 +++ board/ti/j721e/Kconfig| 54 board/ti/j721e/Makefile | 8 + board/ti/j721e/evm.c | 68 ++ configs/j721e_evm_a72_defconfig | 86 +++ configs/j721e_evm_r5_defconfig| 85 +++ drivers/mmc/am654_sdhci.c | 114 + include/configs/j721e_evm.h | 102 include/dt-bindings/pinctrl/k3.h | 3 + 25 files changed, 1571 insertions(+), 51 deletions(-) create mode 100644 arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi create mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts create mode 100644 arch/arm/dts/k3-j721e-main.dtsi create mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board.dts create mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi create mode 100644 arch/arm/dts/k3-j721e.dtsi create mode 100644 arch/arm/mach-k3/include/mach/j721e_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/j721e_spl.h create mode 100644 arch/arm/mach-k3/j721e_init.c create mode 100644 board/ti/j721e/Kconfig create mode 100644 board/ti/j721e/Makefile create mode 100644 board/ti/j721e/evm.c create mode 100644 configs/j721e_evm_a72_defconfig create mode 100644 configs/j721e_evm_r5_defconfig create mode 100644 include/configs/j721e_evm.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/14] arm: dts: j721e: Add r5 specific dt support
Add initial support for dt that runs on r5.
Signed-off-by: Lokesh Vutla
Signed-off-by: Andreas Dannenberg
---
arch/arm/dts/Makefile | 3 +-
.../k3-j721e-common-proc-board-u-boot.dtsi| 75 ++
.../arm/dts/k3-j721e-r5-common-proc-board.dts | 138 ++
3 files changed, 215 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 818d66a17a..89a12f6c9f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -750,7 +750,8 @@ dtb-$(CONFIG_TARGET_STM32MP1) += \
stm32mp157c-ev1.dtb
dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-board.dtb
-dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb
+dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
+ k3-j721e-r5-common-proc-board.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-bananapi-bpi-r2.dtb \
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
new file mode 100644
index 00..541da22c48
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/ {
+ chosen {
+ stdout-path = "serial2:115200n8";
+ tick-timer =
+ };
+};
+
+_main{
+ u-boot,dm-spl;
+};
+
+_mcu_wakeup {
+ u-boot,dm-spl;
+
+ timer1: timer@4040 {
+ compatible = "ti,omap5430-timer";
+ reg = <0x0 0x4040 0x0 0x80>;
+ ti,timer-alwon;
+ clock-frequency = <2500>;
+ u-boot,dm-spl;
+ };
+};
+
+_proxy_main {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+ k3_sysreset: sysreset-controller {
+ compatible = "ti,sci-sysreset";
+ u-boot,dm-spl;
+ };
+};
+
+_pds {
+ u-boot,dm-spl;
+};
+
+_clks {
+ u-boot,dm-spl;
+};
+
+_reset {
+ u-boot,dm-spl;
+};
+
+_pmx0 {
+ u-boot,dm-spl;
+};
+
+_pmx0 {
+ u-boot,dm-spl;
+};
+
+_uart0 {
+ u-boot,dm-spl;
+};
+
+_uart0 {
+ u-boot,dm-spl;
+};
+
+_sdhci0 {
+ u-boot,dm-spl;
+};
+
+_sdhci1 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
new file mode 100644
index 00..5d8883e2f5
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-j721e-som-p0.dtsi"
+
+/ {
+ aliases {
+ remoteproc0 =
+ remoteproc1 = _0;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ tick-timer =
+ };
+
+ a72_0: a72@0 {
+ compatible = "ti,am654-rproc";
+ reg = <0x0 0x00a9 0x0 0x10>;
+ power-domains = <_pds 61>, <_pds 202>;
+ resets = <_reset 202 0>;
+ ti,sci = <>;
+ ti,sci-proc-id = <32>;
+ ti,sci-host-id = <10>;
+ u-boot,dm-spl;
+ };
+
+ clk_200mhz: dummy_clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2>;
+ u-boot,dm-spl;
+ };
+};
+
+_mcu_wakeup {
+ mcu_secproxy: secproxy@2838 {
+ u-boot,dm-spl;
+ compatible = "ti,am654-secure-proxy";
+ reg = <0x0 0x2a38 0x0 0x8>,
+ <0x0 0x2a40 0x0 0x8>,
+ <0x0 0x2a48 0x0 0x8>;
+ reg-names = "rt", "scfg", "target_data";
+ #mbox-cells = <1>;
+ };
+
+ sysctrler: sysctrler {
+ u-boot,dm-spl;
+ compatible = "ti,am654-system-controller";
+ mboxes= <_secproxy 4>, <_secproxy 5>;
+ mbox-names = "tx", "rx";
+ };
+};
+
+ {
+ mboxes= <_secproxy 8>, <_secproxy 6>, <_secproxy 5>;
+ mbox-names = "tx", "rx", "notify";
+ ti,host-id = <4>;
+ ti,secure-host;
+};
+
+_pmx0 {
+ wkup_uart0_pins_default: wkup_uart0_pins_default {
+ u-boot,dm-spl;
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0xa0, PIN_INPUT, 0) /* (J29)
WKUP_UART0_RXD */
+ J721E_WKUP_IOPAD(0xa4, PIN_OUTPUT, 0) /* (J28)
WKUP_UART0_TXD */
+ >;
+ };
+
+ mcu_uart0_pins_default: mcu_uart0_pins_default {
+ u-boot,dm-spl;
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0xe8,
[U-Boot] [PATCH 01/14] arm: K3: j721e: Add basic support for J721E SoC definition
The J721E SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable lower system costs
of automotive applications such as infotainment, cluster, premium
Audio, Gateway, industrial and a range of broad market applications.
This SoC is designed around reducing the system cost by eliminating
the need of an external system MCU and is targeted towards ASIL-B/C
certification/requirements in addition to allowing complex software
and system use-cases.
Some highlights of this SoC are:
* Dual Cortex-A72s in a single cluster, three clusters of lockstep
capable dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA),
C7x floating point Vector DSP, Two C66x floating point DSPs.
* 3D GPU PowerVR Rogue 8XE GE8430
* Vision Processing Accelerator (VPAC) with image signal processor and Depth
and Motion Processing Accelerator (DMPAC)
* Two Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Two CSI2.0 4L RX plus one CSI2.0 4L TX, one eDP/DP, One DSI Tx, and
up to two DPI interfaces.
* Integrated Ethernet switch supporting up to a total of 8 external ports in
addition to legacy Ethernet switch of up to 2 ports.
* System MMU (SMMU) Version 3.0 and advanced virtualisation
capabilities.
* Upto 4 PCIe-GEN3 controllers, 2 USB3.0 Dual-role device subsystems,
16 MCANs, 12 McASP, eMMC and SD, UFS, OSPI/HyperBus memory controller, QSPI,
I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
* Two hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
management.
* Configurable L3 Cache and IO-coherent architecture with high data throughput
capable distributed DMA architecture under NAVSS
* Centralized System Controller for Security, Power, and Resource
Management (DMSC)
See J721E Technical Reference Manual (SPRUIL1, May 2019)
for further details: http://www.ti.com/lit/pdf/spruil1
Add base support for J721E SoC
Signed-off-by: Lokesh Vutla
Signed-off-by: Andreas Dannenberg
Signed-off-by: Nishanth Menon
---
arch/arm/mach-k3/Kconfig | 12 ++--
arch/arm/mach-k3/Makefile | 1 +
arch/arm/mach-k3/am6_init.c | 6 --
arch/arm/mach-k3/common.c | 6 ++
arch/arm/mach-k3/j721e_init.c | 34 ++
5 files changed, 51 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/mach-k3/j721e_init.c
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index f1731dda58..5c5b3dda8b 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -7,6 +7,9 @@ choice
config SOC_K3_AM6
bool "TI's K3 based AM6 SoC Family Support"
+config SOC_K3_J721E
+ bool "TI's K3 based J721E SoC Family Support"
+
endchoice
config SYS_SOC
@@ -14,7 +17,8 @@ config SYS_SOC
config SYS_K3_NON_SECURE_MSRAM_SIZE
hex
- default 0x8
+ default 0x8 if SOC_K3_AM6
+ default 0x10 if SOC_K3_J721E
help
Describes the total size of the MCU MSRAM. This doesn't
specify the total size of SPL as ROM can use some part
@@ -23,7 +27,8 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE
config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
hex
- default 0x58000
+ default 0x58000 if SOC_K3_AM6
+ default 0xc if SOC_K3_J721E
help
Describes the maximum size of the image that ROM can download
from any boot media.
@@ -31,18 +36,21 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
config SYS_K3_MCU_SCRATCHPAD_BASE
hex
default 0x4028 if SOC_K3_AM6
+ default 0x4028 if SOC_K3_J721E
help
Describes the base address of MCU Scratchpad RAM.
config SYS_K3_MCU_SCRATCHPAD_SIZE
hex
default 0x200 if SOC_K3_AM6
+ default 0x200 if SOC_K3_J721E
help
Describes the size of MCU Scratchpad RAM.
config SYS_K3_BOOT_PARAM_TABLE_INDEX
hex
default 0x41c7fbfc if SOC_K3_AM6
+ default 0x41cffc00 if SOC_K3_J721E
help
Address at which ROM stores the value which determines if SPL
is booted up by primary boot media or secondary boot media.
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 6c895400c2..b27de4a934 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -4,6 +4,7 @@
# Lokesh Vutla
obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
+obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o
obj-$(CONFIG_ARM64) += arm64-mmu.o
obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 335f8ef16a..a19bf327be 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -213,12 +213,6 @@ u32 spl_boot_device(void)
}
#endif
-#ifndef CONFIG_SYSRESET
-void reset_cpu(ulong ignored)
-{
-}
-#endif
-
#ifdef CONFIG_SYS_K3_SPL_ATF
#define AM6_DEV_MCU_RTI0 134
diff --git
[U-Boot] [PATCH 14/14] configs: j721e_evm_a72: Add initial support
Add initial defconfig support for J721e that runs on A72.
Signed-off-by: Lokesh Vutla
---
configs/j721e_evm_a72_defconfig | 86 +
1 file changed, 86 insertions(+)
create mode 100644 configs/j721e_evm_a72_defconfig
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
new file mode 100644
index 00..237dc6b601
--- /dev/null
+++ b/configs/j721e_evm_a72_defconfig
@@ -0,0 +1,86 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SOC_K3_J721E=y
+CONFIG_TARGET_J721E_A72_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_DISTRO_DEFAULTS=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_TEXT_BASE=0x8008
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+CONFIG_CMD_SF=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT4_WRITE=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-common-proc-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_OF_LIBFDT_OVERLAY=y
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/14] armV7R: K3: j721e: Store boot index from ROM
From: Andreas Dannenberg
Obtain the boot index as left behind by the device boot ROM and store
it in scratch pad SRAM for later use before it may get overwritten.
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/j721e_init.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 7c288a1e6f..211ca448aa 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -53,12 +53,25 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(CTRL_MMR0_BASE, 7);
}
+/*
+ * This uninitialized global variable would normal end up in the .bss section,
+ * but the .bss is cleared between writing and reading this variable, so move
+ * it to the .data section.
+ */
+u32 bootindex __attribute__((section(".data")));
+
+static void store_boot_index_from_rom(void)
+{
+ bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
+}
+
void board_init_f(ulong dummy)
{
/*
-* ToDo:
-* - Store boot rom index.
+* Cannot delay this further as there is a chance that
+* K3_BOOT_PARAM_TABLE_INDEX can be over written by SPL MALLOC section.
*/
+ store_boot_index_from_rom();
/* Make all control module registers accessible */
ctrl_mmr_unlock();
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/14] armV7R: K3: j721e: Unlock all applicable control MMR registers
From: Andreas Dannenberg
To access various control MMR functionality the registers need to
be unlocked. Do that for all control MMR regions in the MCU and MAIN
domains. We may want to go back later and limit the unlocking that's
being done.
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/j721e_init.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 6da4cf6d22..7c288a1e6f 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -14,14 +14,55 @@
#include "common.h"
#ifdef CONFIG_SPL_BUILD
+static void mmr_unlock(u32 base, u32 partition)
+{
+ /* Translate the base address */
+ phys_addr_t part_base = base + partition * CTRL_MMR0_PARTITION_SIZE;
+
+ /* Unlock the requested partition if locked using two-step sequence */
+ writel(CTRLMMR_LOCK_KICK0_UNLOCK_VAL, part_base + CTRLMMR_LOCK_KICK0);
+ writel(CTRLMMR_LOCK_KICK1_UNLOCK_VAL, part_base + CTRLMMR_LOCK_KICK1);
+}
+
+static void ctrl_mmr_unlock(void)
+{
+ /* Unlock all WKUP_CTRL_MMR0 module registers */
+ mmr_unlock(WKUP_CTRL_MMR0_BASE, 0);
+ mmr_unlock(WKUP_CTRL_MMR0_BASE, 1);
+ mmr_unlock(WKUP_CTRL_MMR0_BASE, 2);
+ mmr_unlock(WKUP_CTRL_MMR0_BASE, 3);
+ mmr_unlock(WKUP_CTRL_MMR0_BASE, 4);
+ mmr_unlock(WKUP_CTRL_MMR0_BASE, 6);
+ mmr_unlock(WKUP_CTRL_MMR0_BASE, 7);
+
+ /* Unlock all MCU_CTRL_MMR0 module registers */
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 0);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 1);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 2);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 3);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 4);
+
+ /* Unlock all CTRL_MMR0 module registers */
+ mmr_unlock(CTRL_MMR0_BASE, 0);
+ mmr_unlock(CTRL_MMR0_BASE, 1);
+ mmr_unlock(CTRL_MMR0_BASE, 2);
+ mmr_unlock(CTRL_MMR0_BASE, 3);
+ mmr_unlock(CTRL_MMR0_BASE, 4);
+ mmr_unlock(CTRL_MMR0_BASE, 5);
+ mmr_unlock(CTRL_MMR0_BASE, 6);
+ mmr_unlock(CTRL_MMR0_BASE, 7);
+}
+
void board_init_f(ulong dummy)
{
/*
* ToDo:
* - Store boot rom index.
-* - unlock mmr.
*/
+ /* Make all control module registers accessible */
+ ctrl_mmr_unlock();
+
#ifdef CONFIG_CPU_V7R
setup_k3_mpu_regions();
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/14] armV7R: K3: j721e: Allow using SPL BSS pre-relocation
From: Andreas Dannenberg In order to be able to use more advanced driver functionality which often relies on having BSS initialized during early boot prior to relocation several things need to be in place: 1) Memory needs to be available for BSS to use. For this, we locate BSS at the top of the MCU SRAM area, with the stack starting right below it, 2) We need to zero-initialize BSS ourselves which will we do during board_init_f(), 3) We would also like to skip the implicit zero-initialization as part of SPL relocation, so that already initialized variables will carry over post-relocation. We will do this with a separate commit by turning on the respective CONFIG option. In this commit we only zero-initialize BSS. Assignment of SP will be done in the environment setup. Signed-off-by: Andreas Dannenberg Signed-off-by: Lokesh Vutla --- arch/arm/mach-k3/j721e_init.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c index d798aed481..6da4cf6d22 100644 --- a/arch/arm/mach-k3/j721e_init.c +++ b/arch/arm/mach-k3/j721e_init.c @@ -24,6 +24,13 @@ void board_init_f(ulong dummy) #ifdef CONFIG_CPU_V7R setup_k3_mpu_regions(); + + /* +* When running SPL on R5 we are using SRAM for BSS to have global +* data etc. working prior to relocation. Since this means we need +* to self-manage BSS, clear that section now. +*/ + memset(__bss_start, 0, __bss_end - __bss_start); #endif /* Init DM early */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/14] board: ti: j721e: Add board support for j721e evm
Add board specific initialization for j721e evm
Signed-off-by: Lokesh Vutla
Signed-off-by: Jean-Jacques Hiblot
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/Kconfig| 1 +
board/ti/j721e/Kconfig | 54 +++
board/ti/j721e/Makefile | 8 +++
board/ti/j721e/evm.c| 68
include/configs/j721e_evm.h | 102
5 files changed, 233 insertions(+)
create mode 100644 board/ti/j721e/Kconfig
create mode 100644 board/ti/j721e/Makefile
create mode 100644 board/ti/j721e/evm.c
create mode 100644 include/configs/j721e_evm.h
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 5c5b3dda8b..dd18f5e87e 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -114,4 +114,5 @@ config SYS_K3_SPL_ATF
after SPL from R5.
source "board/ti/am65x/Kconfig"
+source "board/ti/j721e/Kconfig"
endif
diff --git a/board/ti/j721e/Kconfig b/board/ti/j721e/Kconfig
new file mode 100644
index 00..ede9177805
--- /dev/null
+++ b/board/ti/j721e/Kconfig
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+# Lokesh Vutla
+
+choice
+ prompt "K3 J721E based boards"
+ optional
+
+config TARGET_J721E_A72_EVM
+ bool "TI K3 based J721E EVM running on A72"
+ select ARM64
+ select SOC_K3_J721E
+ select SYS_DISABLE_DCACHE_OPS
+
+config TARGET_J721E_R5_EVM
+ bool "TI K3 based J721E EVM running on R5"
+ select CPU_V7R
+ select SYS_THUMB_BUILD
+ select SOC_K3_J721E
+ select RAM
+ select SPL_RAM
+ imply SYS_K3_SPL_ATF
+
+endchoice
+
+if TARGET_J721E_A72_EVM
+
+config SYS_BOARD
+ default "j721e"
+
+config SYS_VENDOR
+ default "ti"
+
+config SYS_CONFIG_NAME
+ default "j721e_evm"
+
+endif
+
+if TARGET_J721E_R5_EVM
+
+config SYS_BOARD
+ default "j721e"
+
+config SYS_VENDOR
+ default "ti"
+
+config SYS_CONFIG_NAME
+ default "j721e_evm"
+
+config SPL_LDSCRIPT
+ default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+endif
diff --git a/board/ti/j721e/Makefile b/board/ti/j721e/Makefile
new file mode 100644
index 00..97535f5d86
--- /dev/null
+++ b/board/ti/j721e/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+# Lokesh Vutla
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += evm.o
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
new file mode 100644
index 00..43d502b6ca
--- /dev/null
+++ b/board/ti/j721e/evm.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Board specific initialization for J721E EVM
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ *
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+#ifdef CONFIG_PHYS_64BIT
+ gd->ram_size = 0x1;
+#else
+ gd->ram_size = 0x8000;
+#endif
+
+ return 0;
+}
+
+ulong board_get_usable_ram_top(ulong total_size)
+{
+#ifdef CONFIG_PHYS_64BIT
+ /* Limit RAM used by U-Boot to the DDR low region */
+ if (gd->ram_top > 0x1)
+ return 0x1;
+#endif
+
+ return gd->ram_top;
+}
+
+int dram_init_banksize(void)
+{
+ /* Bank 0 declares the memory available in the DDR low region */
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = 0x8000;
+ gd->ram_size = 0x8000;
+
+#ifdef CONFIG_PHYS_64BIT
+ /* Bank 1 declares the memory available in the DDR high region */
+ gd->bd->bi_dram[1].start = CONFIG_SYS_SDRAM_BASE1;
+ gd->bd->bi_dram[1].size = 0x8000;
+ gd->ram_size = 0x1;
+#endif
+
+ return 0;
+}
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+ if (!strcmp(name, "k3-j721e-common-proc-board"))
+ return 0;
+
+ return -1;
+}
+#endif
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
new file mode 100644
index 00..f61163904c
--- /dev/null
+++ b/include/configs/j721e_evm.h
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Configuration header file for K3 J721E EVM
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#ifndef __CONFIG_J721E_EVM_H
+#define __CONFIG_J721E_EVM_H
+
+#include
+#include
+#include
+
+#define CONFIG_ENV_SIZE(128 << 10)
+
+/* DDR Configuration */
+#define CONFIG_SYS_SDRAM_BASE1 0x88000
+
+/* SPL Loader Configuration */
+#ifdef CONFIG_TARGET_J721E_A72_EVM
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\
+CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE)
+#define
[U-Boot] [PATCH 02/14] armV7R: K3: j721e: Add support for boot device detection
J721E allows for booting from primary or backup boot media. Both media can be chosen individually based on switch settings. ROM looks for a valid image in primary boot media, if not found then looks in backup boot media. In order to pass this boot media information to boot loader, ROM stores a value at a particular address. Add support for reading this information and determining the boot media correctly. Signed-off-by: Lokesh Vutla Signed-off-by: Andreas Dannenberg --- arch/arm/mach-k3/include/mach/hardware.h | 4 ++ .../arm/mach-k3/include/mach/j721e_hardware.h | 52 +++ arch/arm/mach-k3/include/mach/j721e_spl.h | 31 +++ arch/arm/mach-k3/include/mach/spl.h | 4 ++ arch/arm/mach-k3/j721e_init.c | 46 5 files changed, 137 insertions(+) create mode 100644 arch/arm/mach-k3/include/mach/j721e_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/j721e_spl.h diff --git a/arch/arm/mach-k3/include/mach/hardware.h b/arch/arm/mach-k3/include/mach/hardware.h index b39f780d26..4e629822aa 100644 --- a/arch/arm/mach-k3/include/mach/hardware.h +++ b/arch/arm/mach-k3/include/mach/hardware.h @@ -9,4 +9,8 @@ #ifdef CONFIG_SOC_K3_AM6 #include "am6_hardware.h" #endif + +#ifdef CONFIG_SOC_K3_J721E +#include "j721e_hardware.h" +#endif #endif /* _ASM_ARCH_HARDWARE_H_ */ diff --git a/arch/arm/mach-k3/include/mach/j721e_hardware.h b/arch/arm/mach-k3/include/mach/j721e_hardware.h new file mode 100644 index 00..4f84b76af6 --- /dev/null +++ b/arch/arm/mach-k3/include/mach/j721e_hardware.h @@ -0,0 +1,52 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * K3: J721E SoC definitions, structures etc. + * + * (C) Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/ + */ +#ifndef __ASM_ARCH_J721E_HARDWARE_H +#define __ASM_ARCH_J721E_HARDWARE_H + +#include + +#define CTRL_MMR0_BASE 0x0010 +#define CTRLMMR_MAIN_DEVSTAT (CTRL_MMR0_BASE + 0x30) + +#define MAIN_DEVSTAT_BOOT_MODE_B_MASK BIT(0) +#define MAIN_DEVSTAT_BOOT_MODE_B_SHIFT 0 +#define MAIN_DEVSTAT_BKUP_BOOTMODE_MASKGENMASK(3, 1) +#define MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT 1 +#define MAIN_DEVSTAT_PRIM_BOOTMODE_MMC_PORT_MASK BIT(6) +#define MAIN_DEVSTAT_PRIM_BOOTMODE_PORT_SHIFT 6 + +#define WKUP_CTRL_MMR0_BASE0x4300 +#define MCU_CTRL_MMR0_BASE 0x40f0 + +#define CTRLMMR_WKUP_DEVSTAT (WKUP_CTRL_MMR0_BASE + 0x30) +#define WKUP_DEVSTAT_PRIMARY_BOOTMODE_MASK GENMASK(5, 3) +#define WKUP_DEVSTAT_PRIMARY_BOOTMODE_SHIFT3 +#define WKUP_DEVSTAT_MCU_OMLY_MASK BIT(6) +#define WKUP_DEVSTAT_MCU_ONLY_SHIFT6 + +/* + * The CTRL_MMR0 memory space is divided into several equally-spaced + * partitions, so defining the partition size allows us to determine + * register addresses common to those partitions. + */ +#define CTRL_MMR0_PARTITION_SIZE 0x4000 + +/* + * CTRL_MMR0, WKUP_CTRL_MMR0, and MCU_CTR_MMR0 lock/kick-mechanism + * shared register definitions. + */ +#define CTRLMMR_LOCK_KICK0 0x01008 +#define CTRLMMR_LOCK_KICK0_UNLOCK_VAL 0x68ef3490 +#define CTRLMMR_LOCK_KICK0_UNLOCKED_MASK BIT(0) +#define CTRLMMR_LOCK_KICK0_UNLOCKED_SHIFT 0 +#define CTRLMMR_LOCK_KICK1 0x0100c +#define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a + +/* MCU SCRATCHPAD usage */ +#define K3_BOOT_PARAM_TABLE_INDEX_VAL CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE + +#endif /* __ASM_ARCH_J721E_HARDWARE_H */ diff --git a/arch/arm/mach-k3/include/mach/j721e_spl.h b/arch/arm/mach-k3/include/mach/j721e_spl.h new file mode 100644 index 00..f37e6da0db --- /dev/null +++ b/arch/arm/mach-k3/include/mach/j721e_spl.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/ + * Lokesh Vutla + */ +#ifndef _ASM_ARCH_J721E_SPL_H_ +#define _ASM_ARCH_J721E_SPL_H_ + +/* With BootMode B = 0 */ +#define BOOT_DEVICE_HYPERFLASH 0x00 +#define BOOT_DEVICE_OSPI 0x01 +#define BOOT_DEVICE_QSPI 0x02 +#define BOOT_DEVICE_SPI0x03 +#define BOOT_DEVICE_ETHERNET 0x04 +#define BOOT_DEVICE_I2C0x06 +#define BOOT_DEVICE_UART 0x07 + +/* With BootMode B = 1 */ +#define BOOT_DEVICE_MMC1 0x10 +#define BOOT_DEVICE_MMC2 0x11 +#define BOOT_DEVICE_USB0x12 +#define BOOT_DEVICE_UFS0x13 +#define BOOT_DEVIE_GPMC0x14 +#define BOOT_DEVICE_PCIE 0x15 +#define BOOT_DEVICE_MMC2_2 0x16 +#define BOOT_DEVICE_RAM0x17 + +#define BOOT_MODE_B_SHIFT 4
Re: [U-Boot] [PATCH v5] board/fsl/lx2160a: Fix MC firmware loading during SD boot
> -Original Message- > From: Pankaj Bansal > Sent: Monday, April 15, 2019 9:39 AM > To: Prabhakar Kushwaha ; Meenakshi > Aggarwal ; Priyanka Jain > > Cc: u-boot@lists.denx.de > Subject: RE: [PATCH v5] board/fsl/lx2160a: Fix MC firmware loading during SD > boot > > > > > -Original Message- > > From: Prabhakar Kushwaha > > Sent: Wednesday, 27 March, 2019 11:50 AM > > To: Pankaj Bansal ; Meenakshi Aggarwal > > ; Priyanka Jain > > Cc: u-boot@lists.denx.de > > Subject: RE: [PATCH v5] board/fsl/lx2160a: Fix MC firmware loading > > during SD boot > > > > > > > -Original Message- > > > From: Pankaj Bansal > > > Sent: Monday, March 25, 2019 5:28 PM > > > To: Meenakshi Aggarwal ; Priyanka Jain > > > ; Prabhakar Kushwaha > > > > > > Cc: u-boot@lists.denx.de; Pankaj Bansal > > > Subject: [PATCH v5] board/fsl/lx2160a: Fix MC firmware loading > > > during SD boot > > > > > > during SD boot, following error comes: > > > MMC read: dev # 0, block # 20480, count 2048 ... 2048 blocks read: > > > OK > > > > > > MMC read: dev # 0, block # 28672, count 2048 ... 2048 blocks read: OK > > > fsl-mc: ERR: Bad firmware image (bad FIT header) > > > Hit any key to stop autoboot: 0 > > > > > > it's occurring because mc 10.14.3 file size is 1064880, which means > > > 0x820 SD blocks which is more than 0x800 blocks (1MB). This results > > > in DPC loading address 0x8010 overlapping with MC loading > > > address > > 0x8000. > > > > > > so, update the MC/dpl/dpc addresses as per their addresses in SD card. > > > Assuming that SD card block size is 512 bytes and 0x0 block in SD > > > card would get loaded at 0x8000 (DDR base address), this gives > > > following addresses for various binaries: > > > > > > Binary | SD block | DDR offset > > > -- > > > MC | 0x5000 | 0x80a0 > > > DPL| 0x6800 | 0x80d0 > > > DPC| 0x7000 | 0x80e0 > > > > > > > This info should be part of README present in board folder. > > No need to add in commit message. > > It is. Please check https://elixir.bootlin.com/u- > boot/latest/source/board/freescale/lx2160a/README#L68 Yes, It is part of README. This is the reason, I asking to remove from commit message. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] mmc: fsl_esdhc: fix probe issue without CONFIG_BLK enabled
> -Original Message-
> From: Yinbo Zhu
> Sent: Wednesday, May 15, 2019 3:38 PM
> To: York Sun ; u-boot@lists.denx.de; Vabhav Sharma
>
> Cc: Yinbo Zhu ; Xiaobo Xie ; Jiafei
> Pan ; Y.b. Lu ; Jagdish Gediya
> ; Prabhakar Kushwaha
> ; Andy Tang
> Subject: [PATCH v4 2/2] mmc: fsl_esdhc: fix probe issue without CONFIG_BLK
> enabled
>
> From: Yangbo Lu
>
> u-boot is trying to make CONFIG_BLK as a hard requirement for DM_MMC. But
> now it's still not.
>
> config BLK
> bool "Support block devices"
> depends on DM
> default y if DM_MMC
>
> When fsl_esdhc driver was reworked for DM_MMC support, DM_MMC without
> CONFIG_BLK enabled wasn't considered. This patch is to fix probe issue without
> CONFIG_BLK enabled.
>
> Signed-off-by: Yangbo Lu
> Signed-off-by: Yinbo Zhu
> ---
> Change in v4:
> Update the Copyright
>
Adding complete history
> drivers/mmc/fsl_esdhc.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> 9e34557d16..53277c9216 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2007, 2010-2011 Freescale Semiconductor, Inc
> + * Copyright 2007, 2010-2020 Freescale Semiconductor, Inc
> * Andy Fleming
> *
Freescale was there till 2016.
After that it is NXP. So add NXP copyright.
Please resend this patch.
> * Based vaguely on the pxa mmc code:
> @@ -25,6 +25,10 @@
> #include
> #include
>
> +#if !CONFIG_IS_ENABLED(BLK)
> +#include "mmc_private.h"
> +#endif
> +
> DECLARE_GLOBAL_DATA_PTR;
>
> #define SDHCI_IRQ_EN_BITS(IRQSTATEN_CC | IRQSTATEN_TC | \
> @@ -34,6 +38,7 @@ DECLARE_GLOBAL_DATA_PTR;
> IRQSTATEN_DEBE | IRQSTATEN_BRR |
> IRQSTATEN_BWR | \
> IRQSTATEN_DINT)
> #define MAX_TUNING_LOOP 40
> +#define ESDHC_DRIVER_STAGE_VALUE 0x
>
> struct fsl_esdhc {
> uintdsaddr; /* SDMA system address register */
> @@ -1448,6 +1453,9 @@ static int fsl_esdhc_probe(struct udevice *dev)
> fdt_addr_t addr;
> unsigned int val;
> struct mmc *mmc;
> +#if !CONFIG_IS_ENABLED(BLK)
> + struct blk_desc *bdesc;
> +#endif
> int ret;
>
> addr = dev_read_addr(dev);
> @@ -1576,6 +1584,26 @@ static int fsl_esdhc_probe(struct udevice *dev)
> mmc = >mmc;
> mmc->cfg = >cfg;
> mmc->dev = dev;
> +#if !CONFIG_IS_ENABLED(BLK)
> + mmc->priv = priv;
> +
> + /* Setup dsr related values */
> + mmc->dsr_imp = 0;
> + mmc->dsr = ESDHC_DRIVER_STAGE_VALUE;
> + /* Setup the universal parts of the block interface just once */
> + bdesc = mmc_get_blk_desc(mmc);
> + bdesc->if_type = IF_TYPE_MMC;
> + bdesc->removable = 1;
> + bdesc->devnum = mmc_get_next_devnum();
> + bdesc->block_read = mmc_bread;
> + bdesc->block_write = mmc_bwrite;
> + bdesc->block_erase = mmc_berase;
> +
> + /* setup initial part type */
> + bdesc->part_type = mmc->cfg->part_type;
> + mmc_list_add(mmc);
> +#endif
> +
> upriv->mmc = mmc;
>
> return esdhc_init_common(priv, mmc);
@ Peng. Can you please ack on this patch
--pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] armv8: fsl-lsch3: add clock support for the second eSDHC
> -Original Message- > From: Yinbo Zhu > Sent: Wednesday, May 15, 2019 3:38 PM > To: York Sun ; u-boot@lists.denx.de; Vabhav Sharma > > Cc: Yinbo Zhu ; Xiaobo Xie ; Jiafei > Pan ; Y.b. Lu ; Jagdish Gediya > ; Prabhakar Kushwaha > ; Andy Tang > Subject: [PATCH v4 1/2] armv8: fsl-lsch3: add clock support for the second > eSDHC > > From: Yangbo Lu > > Layerscape began to use two eSDHC controllers, for example, LS1028A. They > are same IP block with same reference clock. > This patch is to add clock support for the second eSDHC. > > Signed-off-by: Yangbo Lu > Signed-off-by: Yinbo Zhu > --- > Change in v4: > Update the Copyright > Please maintain complete history > arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 3 ++- > arch/arm/include/asm/arch-fsl-layerscape/clock.h| 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > index bc268e207c..0985778ff9 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0+ > /* > - * Copyright 2014-2015, Freescale Semiconductor, Inc. > + * Copyright 2014-2015, 2018 Freescale Semiconductor, Inc. Freescale was there till 2016. After that it was NXP. So please start adding NXP copyright /* * Copyright 2017-2019 NXP */ --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v1] ls1028a: hdp: Add support for HDP firmware loading
Dear Anatolij Gustschin > -Original Message- > From: Wen He > Sent: Wednesday, May 15, 2019 3:32 PM > To: Prabhakar Kushwaha ; Jagdish Gediya > ; Alison Wang ; > ag...@denx.de; Oliver Brown ; u-boot@lists.denx.de > Cc: Wen He > Subject: [v1] ls1028a: hdp: Add support for HDP firmware loading > > From: Alison Wang > > This patch adds a command to load the HDP firmware and supporting > libraries. > > Signed-off-by: Oliver Brown > Signed-off-by: Alison Wang > Signed-off-by: Wen He > --- > configs/ls1028aqds_tfa_defconfig| 2 + > configs/ls1028ardb_tfa_defconfig| 2 + > drivers/video/Kconfig | 9 + > drivers/video/Makefile | 1 + > drivers/video/imx/Makefile | 8 + > drivers/video/imx/hdp/API_General.c | 473 > drivers/video/imx/hdp/API_General.h | 275 ++ > drivers/video/imx/hdp/Makefile | 6 + > drivers/video/imx/hdp/address.h | 78 > drivers/video/imx/hdp/apb_cfg.h | 155 > drivers/video/imx/hdp/externs.h | 54 +++ > drivers/video/imx/hdp/general_handler.h | 132 +++ > drivers/video/imx/hdp/opcodes.h | 85 + > drivers/video/imx/hdp/test_base_sw.c| 216 +++ > drivers/video/imx/hdp/util.h| 256 + > drivers/video/imx/hdp_load.c| 58 +++ > 16 files changed, 1810 insertions(+) > create mode 100644 drivers/video/imx/Makefile > create mode 100644 drivers/video/imx/hdp/API_General.c > create mode 100644 drivers/video/imx/hdp/API_General.h > create mode 100644 drivers/video/imx/hdp/Makefile > create mode 100644 drivers/video/imx/hdp/address.h > create mode 100644 drivers/video/imx/hdp/apb_cfg.h > create mode 100644 drivers/video/imx/hdp/externs.h > create mode 100644 drivers/video/imx/hdp/general_handler.h > create mode 100644 drivers/video/imx/hdp/opcodes.h > create mode 100644 drivers/video/imx/hdp/test_base_sw.c > create mode 100644 drivers/video/imx/hdp/util.h > create mode 100644 drivers/video/imx/hdp_load.c > Considering this is adding driver in drivers/video folder. Can you please review it. Let me know if I need to delegate to you. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] configs:ls1046afrwy: Add tfa secure boot defonfig.
> -Original Message- > From: U-Boot On Behalf Of Udit Agarwal > Sent: Wednesday, May 15, 2019 2:15 PM > To: u-boot@lists.denx.de > Cc: Ruchika Gupta ; Pramod Kumar > ; Udit Agarwal > Subject: [U-Boot] [PATCH 1/1] configs:ls1046afrwy: Add tfa secure boot > defonfig. > > Add TFA secure boot defconfig and Enables secure boot related configs in it. > > Signed-off-by: Udit Agarwal > --- > configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig | 61 > +++ Make sure to generate defconfig using make savedefconfig. Considering ls1046afrway is not accepted in upstream. Can you please send v2 with dependency of ls1046afrwy patch link Request to send v2. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] RFC: config_distro_bootcmd aesthetic change
I figured I would post this topic without the patchset I currently have, and instead just test the waters to get some input on how the community would feel about this change. What I have done is to migrate all the functions from config_distro_bootcmd.h to be .functions() so by default they are hidden from the env print commands, but are still accessible from env print -a. My reasoning for doing this is as follows. 1) It makes the more common configured environment variables the main output of env print. Especially on a console this makes custom configuration far simpler to grok. 2) With another patch we can then choose the option to not store and restore the .variables to the env instead always accepting the built in defaults. This makes it much simpler to upgrade the logic behind the common distro bootflow with binary firmware updates but without forcing a user to env default -f -a and then reset their custom variables. 3) Reduces the storage size required for an environment on the disk. With the two previous integration changes it reduces my saved environment by almost 4KB. from 4.3KB down to ~500 bytes. I am happy to upload the patches, but again wanted to see if this is even something that the community would even entertain integrating before adding unnecessary patch noise. -Jon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: fsl: lx2160a: implement board_fix_fdt
Dear Pankaj, > -Original Message- > From: Pankaj Bansal > Sent: Friday, May 17, 2019 3:02 PM > To: Prabhakar Kushwaha ; Meenakshi > Aggarwal > Cc: Varun Sethi ; u-boot@lists.denx.de; Pankaj Bansal > > Subject: [PATCH] board: fsl: lx2160a: implement board_fix_fdt > > lx2 rev2 requires some fixups to be applied to fdt before relocation. > Implement the same. > Can you please be more elaborative. What your patch is doing. What kind of fix-up and why it is required? > Signed-off-by: Pankaj Bansal > --- Considering LX2 rev2 is not available has these patches been thoroughly tested on function model. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] rockchip: rk3328: add rock64-rk3328_defconfig
пн, 20 мая 2019 г. в 21:15, Vagrant Cascadian : > > On 2019-05-20, Matwey V. Kornilov wrote: > > пн, 20 мая 2019 г. в 20:11, Vagrant Cascadian : > >> > >> On 2019-05-19, Matwey V. Kornilov wrote: > >> > The ROCK64 is a credit card size SBC based on Rockchip RK3328 > >> > Quad-Core ARM Cortex A53. > >> > > >> > This series allow building u-boot SPL and u-boot.itb for Rock64 > >> > board. The proprietary TPL is stil required for deploy: > >> > > >> > ./tools/mkimage -n rk3328 -T rksd \ > >> > -d ./rkbin/bin/rk33/rk3328_ddr_333MHz_v1.14.bin idbloader.img > >> > cat ./spl/u-boot-spl.bin >> idbloader.img > >> > dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc > >> > dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc > >> > >> Could you add a patch documenting this in doc/README.rockchip or a > >> board-specific README? That would be more useful than having to search > >> the git commit messages or mailing list archives. > >> > >> > >> Tested this patch series against v2019.07-rc2, and I was able to pxe > >> boot fine, but unfortunately was unable to boot from microSD. > >> > >> I presume this is caused by some other change since v2019.07-rc1, since > >> the earlier rock64 patches worked fine with microSD on v2019.07-rc1.\ > > > > Thanks for the report. This series is based on 98b3156b0df4 At least > > bootefi works fine for me. > > No obvious relevent changes between 98b3156b0df4 and v2019.07-rc2. > > I haven't tested with bootefi ... will give that a try too. > > > > Do v1 patches works for you on v2019.07-rc2? > > With some minor rebasing to apply to -rc2, the v1 patches fail in the > same way as the v2 patches on top of v2019.07-rc2. Maybe try to rebase? Could you share your OS image? I can not reproduce the issue now :( > > > live well, > vagrant -- With best regards, Matwey V. Kornilov ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fsl-qoriq master
On Wed, May 22, 2019 at 12:31:23PM +, Prabhakar Kushwaha wrote: > Hi Tom, > > The following changes since commit e1a2ed7180adeefb6164239a18249dca5701319d: > > Merge git://git.denx.de/u-boot-mpc83xx (2019-05-21 07:13:35 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-fsl-qoriq.git HEAD > > for you to fetch changes up to e50663e85d74c4f8015d5157c249cf62c7d0cded: > > armv8: lx2160: Drop useless CONFIG_CMDLINE_EDITING from config.h > (2019-05-22 12:24:25 +0530) > > Travis build log is https://travis-ci.org/prabhukush/u-boot/builds/535646990 > > Changes from rc2 tag > - Support PCIe Gen4 driver of the Mobiveil IP > - NXP LS1028A SoC and platform support > - Few SPI related config updates > - Distinguish the ecc val by chassis version and move the ecc addr to dts > - sp805 watchdog support > 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] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI driver to driver model
Dear Chuanhua, Jagan,
> -Original Message-
> From: U-Boot On Behalf Of Chuanhua Han
> Sent: Thursday, May 9, 2019 9:03 AM
> To: Jagan Teki
> Cc: U-Boot-Denx ; Jiafei Pan ;
> Jagan Teki ; Yinbo Zhu ; Ruchika
> Gupta
> Subject: Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI
> driver to driver model
>
>
>
> > -Original Message-
> > From: Jagan Teki
> > Sent: 2019年5月6日 15:03
> > To: Chuanhua Han
> > Cc: Jagan Teki ; Wolfgang Denk ;
> > Shengzhou Liu ; Ruchika Gupta
> > ; U-Boot-Denx ; Jiafei
> > Pan ; Yinbo Zhu
> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert Freescale
> > ESPI driver to driver model
> >
> > Caution: EXT Email
> >
> > On Mon, May 6, 2019 at 12:29 PM Chuanhua Han
> > wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Jagan Teki
> > > > Sent: 2019年4月26日 2:07
> > > > To: Chuanhua Han
> > > > Cc: Jagan Teki ; Wolfgang Denk ;
> > > > Shengzhou Liu ; Ruchika Gupta
> > > > ; U-Boot-Denx ;
> > > > Jiafei Pan ; Yinbo Zhu
> > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert
> > > > Freescale ESPI driver to driver model
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On Thu, Apr 25, 2019 at 8:27 AM Chuanhua Han
> >
> > > > wrote:
> > > > >
> > > > > Hi,jagan
> > > > > Thank you for your replay!
> > > > >
> > > > > > -Original Message-
> > > > > > From: Jagan Teki
> > > > > > Sent: 2019年4月24日 14:57
> > > > > > To: Chuanhua Han
> > > > > > Cc: Jagan Teki ; Wolfgang Denk
> > > > > > ; Shengzhou Liu ; Ruchika
> > > > > > Gupta ; U-Boot-Denx
> > > > > > ; Jiafei Pan ; Yinbo
> > > > > > Zhu
> > > > > > Subject: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert
> > > > > > Freescale ESPI driver to driver model
> > > > > >
> > > > > > WARNING: This email was created outside of NXP. DO NOT CLICK
> > > > > > links or attachments unless you recognize the sender and know
> > > > > > the content is
> > > > safe.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 23, 2019 at 4:17 PM Chuanhua Han
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Modify the Freescale ESPI driver to support the driver model.
> > > > > > > Also resolved the following problems:
> > > > > > >
> > > > > > > = WARNING == This
> > > > > > > board
> > > > > > does
> > > > > > > not use CONFIG_DM_SPI. Please update the board before
> > > > > > > v2019.04 for no dm conversion and v2019.07 for partially dm
> converted drivers.
> > > > > > > Failure to update can lead to driver/board removal See
> > > > > > > doc/driver-model/MIGRATION.txt for more info.
> > > > > > >
> > > > > > > = WARNING == This
> > > > > > > board
> > > > > > does
> > > > > > > not use CONFIG_DM_SPI_FLASH. Please update the board to use
> > > > > > > CONFIG_SPI_FLASH before the v2019.07 release.
> > > > > > > Failure to update by the deadline may result in board removal.
> > > > > > > See doc/driver-model/MIGRATION.txt for more info.
> > > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Chuanhua Han
> > > > > > > ---
> > > > > > > depends on:
> > > > > > > -
> > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > %2
> > > > > > > F%2F
> > > > > > > patc
> > > > > > >
> > > > > >
> > > >
> > hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99439d
> > > > > > ata
> > > > > > >
> > > > > >
> > > >
> > =02%7C01%7Cchuanhua.han%40nxp.com%7Cfa6bdd7859c4411b5d8608d6c8
> > > > > > 8223e3%7
> > > > > > >
> > > > > >
> > > >
> > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63691685860819371
> > > > > > 5sda
> > > > > > >
> > > > > >
> > > >
> > ta=437CqPexTmJAzhl7wZ3lAUQVbmy%2B2NvHlurTcGTJKT0%3Dreserve
> > > > > > d=0
> > > > > > >
> > > > > > > drivers/spi/fsl_espi.c | 450
> > > > > > > +
> > > > > > > 1 file changed, 316 insertions(+), 134 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
> > > > > > > index 7444ae1a06..6ebe57c30b 100644
> > > > > > > --- a/drivers/spi/fsl_espi.c
> > > > > > > +++ b/drivers/spi/fsl_espi.c
> > > > > > > @@ -4,17 +4,27 @@
> > > > > > > *
> > > > > > > * Copyright 2010-2011 Freescale Semiconductor, Inc.
> > > > > > > * Author: Mingkai Hu (mingkai...@freescale.com)
> > > > > > > + *Chuanhua Han (chuanhua@nxp.com)
> > > > > > > */
> > > > > > >
> > > > > > > #include
> > > > > > > -
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +
> > > > > > > +struct fsl_espi_platdata {
> > > > > > > + uint flags;
> > > > > > > + uint speed_hz;
> > > > > > > + uint num_chipselect;
> > > > > > > + fdt_addr_t regs_addr; };
> > > > > > >
> > > > > > > -struct
Re: [U-Boot] Making U-Boot smaller
Hi Tom, On Wed, May 22, 2019 at 11:09:54AM -0400, Tom Rini wrote: > On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote: > > cc: Yamada-san > > > > I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which > > would point out the culprit configs. This is hardly achievable, but > > looks good on the paper! > > > > CONFIG FILE SIZE > > -- > > CONFIG_FEATURE_A10.7Mi 37.1% > > CONFIG_FEATURE_B5.39Mi 18.6% > > CONFIG_FEATURE_C4.48Mi 15.5% > > CONFIG_FEATURE_D1.86Mi 6.4% > > CONFIG_FEATURE_E1.67Mi 5.8% > > CONFIG_FEATURE_F1.61Mi 5.6% > > CONFIG_FEATURE_G 856Ki 2.9% > > CONFIG_FEATURE_H 470Ki 1.6% > > > > TOTAL 28.9Mi 100.0% > > > > [1] https://github.com/google/bloaty > > This is relatively easy to do today, with buildman and a local commit to > enable/disable CONFIG_FEATURE_A. Being a valid choice doesn't make it necessarily appealing, especially with 512 [1] configurations enabled in sandbox and knowing that U-Boot is not really randconfig-grade [2] (the latter is being improved). What I was alluding to is embedding the Kconfig symbol names into the ELF objects, such that utilities like 'nm' (currently producing a nice output of symbol sizes [3]) can also be made capable to report the exact Kconfig symbols contributing to the size of the objects passed as input. That would be, in my opinion, mind-blowingly useful. [1] grep "CONFIG.*=" .config | wc -l 512 [2] https://patchwork.ozlabs.org/patch/1074420/ [3] nm --print-size --size-sort --radix=d ./drivers/clk/clk-uclass.o 0421 0024 T clk_free 0961 0027 T clk_disable 0888 0027 T clk_enable 0027 T clk_request 0503 0027 T clk_set_parent 0445 0029 T clk_get_rate 0474 0029 T clk_set_rate ... -- Best regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mips: mt76xx: Implement new d-cache fix in last_stage_init()
Am 20.05.19 um 17:22 schrieb Stefan Roese:
> With commit 06985289d452 ("watchdog: Implement generic watchdog_reset()
> version") the init sequence has changed in arch_misc_init(), resulting
> in a re-appearance of the d-cache issue on MT7688 boards (e.g. gardena).
> When this happens, the first (or sometimes later ones as well) TFTP
> command hangs and does not complete correctly. This leads to the
> assumption that the d-cache is not in a clean state once the ethernet
> driver is called (d-cache is used here for the buffers). The old work-
> around with the cache flush somehow does not work any more now with
> the new code change.
>
> Testing has shown, that copying a 64KiB area in DDR at a very late
> bootup time, directly before calling into the prompt, fixes this issue.
> Flushing of the complete d-cache does not seem to necessary, as this
> copy alone seems to fix this problem.
>
> Signed-off-by: Stefan Roese
> Cc: Daniel Schwierzeck
> ---
> arch/mips/Kconfig | 2 +-
> arch/mips/mach-mtmips/cpu.c | 21 -
> 2 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 9cf8e9800d..e3e7945567 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -84,7 +84,7 @@ config ARCH_MTMIPS
> select DM_SERIAL
> imply DM_SPI
> imply DM_SPI_FLASH
> - select ARCH_MISC_INIT
> + select LAST_STAGE_INIT
> select MIPS_TUNE_24KC
> select OF_CONTROL
> select ROM_EXCEPTION_VECTORS
> diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c
> index fcd0484a6d..7afc2c5940 100644
> --- a/arch/mips/mach-mtmips/cpu.c
> +++ b/arch/mips/mach-mtmips/cpu.c
> @@ -69,17 +69,28 @@ int print_cpuinfo(void)
> return 0;
> }
>
> -int arch_misc_init(void)
> +int last_stage_init(void)
> {
> + void *src, *dst;
> +
> + src = malloc(SZ_64K);
> + dst = malloc(SZ_64K);
> + if (!src || !dst) {
> + printf("Can't allocate buffer for cache cleanup copy!\n");
> + return 0;
> + }
> +
> /*
>* It has been noticed, that sometimes the d-cache is not in a
>* "clean-state" when U-Boot is running on MT7688. This was
>* detected when using the ethernet driver (which uses d-cache)
> - * and a TFTP command does not complete. Flushing the complete
> - * d-cache (again?) here seems to fix this issue.
> + * and a TFTP command does not complete. Copying an area of 64KiB
> + * in DDR at a very late bootup time in U-Boot, directly before
> + * calling into the prompt, seems to fix this issue.
>*/
> - flush_dcache_range(gd->bd->bi_memstart,
> -gd->bd->bi_memstart + gd->ram_size - 1);
> + memcpy(dst, src, SZ_64K);
> + free(src);
> + free(dst);
>
> return 0;
> }
>
have you also tried with CONFIG_SYS_MALLOC_CLEAR_ON_INIT? This will run
a memset on the whole malloc area in mem_malloc_init(). This would also
cause a cache line update for all heap memory. May this helps too and
this ugly workaround can go away ;)
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 02/18] arm: omap_i2c: Remove unwanted header file inclusion
From: Vignesh R There is no need for to include this header here, so drop it. Signed-off-by: Vignesh R Reviewed-by: Heiko Schocher Reviewed-by: Lokesh Vutla --- arch/arm/include/asm/omap_i2c.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/omap_i2c.h b/arch/arm/include/asm/omap_i2c.h index c1695cbbee..a6975401da 100644 --- a/arch/arm/include/asm/omap_i2c.h +++ b/arch/arm/include/asm/omap_i2c.h @@ -3,8 +3,6 @@ #ifndef _OMAP_I2C_H #define _OMAP_I2C_H -#include - #ifdef CONFIG_DM_I2C /* Information about a GPIO bank */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 16/18] board: ti: am654: Use EEPROM-based board detection
The TI AM654x EVM base board and the associated daughtercards have on-
board I2C-based EEPROMs containing board configuration data. Use the
board detection infrastructure introduced earlier to do the following:
1) Parse the AM654x EVM base board EEPROM and populate items like board
name and MAC addresses into the TI common EEPROM data structure
residing in SRAM scratch space
2) Check for presence of daughter card(s) by probing the associated
presence signals via an I2C-based GPIO expander. Then, if such a
card is found, parse the data such as additional Ethernet MAC
addresses from its on-board EEPROM and populate into U-Boot
accordingly
3) Dynamically create an U-Boot ENV variable called overlay_files
containing a list of daugherboard-specific DTB overlays based on
daughercards found.
This patch adds support for the AM654x base board ("AM6-COMPROCEVM")
as well as for the IDK ("AM6-IDKAPPEVM"), OLDI LCD ("OLDI-LCD1EVM")
PCIe/USB3.0 ("SER-PCIEUSBEVM"), 2 Lane PCIe/USB2.0 ("SER-PCIE2LEVM"),
and general purpuse ("AM6-GPAPPEVM") daughtercards.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/mach-k3/am6_init.c | 4 +
arch/arm/mach-k3/include/mach/sys_proto.h | 2 +
board/ti/am65x/Kconfig| 7 +
board/ti/am65x/evm.c | 241 ++
include/configs/am65x_evm.h | 9 +-
5 files changed, 257 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 60a580305d..72bce7ce43 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "common.h"
#include
@@ -86,6 +87,9 @@ void board_init_f(ulong dummy)
/* Prepare console output */
preloader_console_init();
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
+
#ifdef CONFIG_K3_AM654_DDRSS
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret)
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 018725b4d1..787a274492 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -12,4 +12,6 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, void
*read_addr,
u32 bound);
struct ti_sci_handle *get_ti_sci_handle(void);
int fdt_fixup_msmc_ram(void *blob, char *parent_path, char *node_name);
+int do_board_detect(void);
+
#endif
diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig
index 98172c28f5..64d9b8cdae 100644
--- a/board/ti/am65x/Kconfig
+++ b/board/ti/am65x/Kconfig
@@ -12,6 +12,8 @@ config TARGET_AM654_A53_EVM
select ARM64
select SOC_K3_AM6
select SYS_DISABLE_DCACHE_OPS
+ select BOARD_LATE_INIT
+ imply TI_I2C_BOARD_DETECT
config TARGET_AM654_R5_EVM
bool "TI K3 based AM654 EVM running on R5"
@@ -20,6 +22,7 @@ config TARGET_AM654_R5_EVM
select SOC_K3_AM6
select K3_AM654_DDRSS
imply SYS_K3_SPL_ATF
+ imply TI_I2C_BOARD_DETECT
endchoice
@@ -34,6 +37,8 @@ config SYS_VENDOR
config SYS_CONFIG_NAME
default "am65x_evm"
+source "board/ti/common/Kconfig"
+
endif
if TARGET_AM654_R5_EVM
@@ -50,4 +55,6 @@ config SYS_CONFIG_NAME
config SPL_LDSCRIPT
default "arch/arm/mach-omap2/u-boot-spl.lds"
+source "board/ti/common/Kconfig"
+
endif
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 52f5d6b11e..7bd8c4fa66 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -8,10 +8,31 @@
*/
#include
+#include
+#include
+#include
+#include
#include
+#include
#include
#include
+#include "../common/board_detect.h"
+
+#define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
+
+/* Daughter card presence detection signals */
+enum {
+ AM65X_EVM_APP_BRD_DET,
+ AM65X_EVM_LCD_BRD_DET,
+ AM65X_EVM_SERDES_BRD_DET,
+ AM65X_EVM_HDMI_GPMC_BRD_DET,
+ AM65X_EVM_BRD_DET_COUNT,
+};
+
+/* Max number of MAC addresses that are parsed/processed per daughter card */
+#define DAUGHTER_CARD_NO_OF_MAC_ADDR 8
+
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
@@ -80,3 +101,223 @@ int ft_board_setup(void *blob, bd_t *bd)
return ret;
}
#endif
+
+int do_board_detect(void)
+{
+ int ret;
+
+ ret = ti_i2c_eeprom_am6_get_base(CONFIG_EEPROM_BUS_ADDRESS,
+CONFIG_EEPROM_CHIP_ADDRESS);
+ if (ret)
+ pr_err("Reading on-board EEPROM at 0x%02x failed %d\n",
+ CONFIG_EEPROM_CHIP_ADDRESS, ret);
+
+ return ret;
+}
+
+static void setup_board_eeprom_env(void)
+{
+ char *name = "am65x";
+
+ if (do_board_detect())
+ goto invalid_eeprom;
+
+ if (board_is_am65x_base_board())
+ name = "am65x";
+ else
+ printf("Unidentified
[U-Boot] [PATCH v2 15/18] ti: common: am6: Add support for setting MAC addresses
The AM654x EVM based on the TI K3 family of SoCs has an updated board
detection EEPROM structure that contains a TLV record of dedicated MAC
addresses rather than a range of MAC addresses as it was used on earlier
platforms such as DRA7. Add a basic function that allows us setting up
Ethernet MAC addresses into the U-Boot environment based on the MAC
address record contained in the common TI EEPROM structure.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
board/ti/common/board_detect.c | 32
board/ti/common/board_detect.h | 12
2 files changed, 44 insertions(+)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index fea39f21e8..32fa10599e 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -534,6 +534,25 @@ fail:
memset(mac_addr, 0, TI_EEPROM_HDR_ETH_ALEN);
}
+void __maybe_unused
+board_ti_am6_get_eth_mac_addr(int index,
+ u8 mac_addr[TI_EEPROM_HDR_ETH_ALEN])
+{
+ struct ti_am6_eeprom *ep = TI_AM6_EEPROM_DATA;
+
+ if (ep->header == TI_DEAD_EEPROM_MAGIC)
+ goto fail;
+
+ if (index < 0 || index >= ep->mac_addr_cnt)
+ goto fail;
+
+ memcpy(mac_addr, ep->mac_addr[index], TI_EEPROM_HDR_ETH_ALEN);
+ return;
+
+fail:
+ memset(mac_addr, 0, TI_EEPROM_HDR_ETH_ALEN);
+}
+
u64 __maybe_unused board_ti_get_emif1_size(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
@@ -667,6 +686,19 @@ void board_ti_set_ethaddr(int index)
}
}
+void board_ti_am6_set_ethaddr(int index, int count)
+{
+ u8 mac_addr[6];
+ int i;
+
+ for (i = 0; i < count; i++) {
+ board_ti_am6_get_eth_mac_addr(i, mac_addr);
+ if (is_valid_ethaddr(mac_addr))
+ eth_env_set_enetaddr_by_index("eth", i + index,
+ mac_addr);
+ }
+}
+
bool __maybe_unused board_ti_was_eeprom_read(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index bf563c84c8..a45d8961b9 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -398,6 +398,18 @@ void set_board_info_env_am6(char *name);
*/
void board_ti_set_ethaddr(int index);
+/**
+ * board_ti_am6_set_ethaddr- Sets the ethaddr environment from EEPROM
+ * @index: The first ethaddr environment variable to set
+ * @count: The number of MAC addresses to process
+ *
+ * EEPROM should be already read before calling this function. The EEPROM
+ * contains n dedicated MAC addresses. This function sets the ethaddr
+ * environment variable for all the available MAC addresses starting
+ * from ethaddr.
+ */
+void board_ti_am6_set_ethaddr(int index, int count);
+
/**
* board_ti_was_eeprom_read() - Check to see if the eeprom contents have been
read
*
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space
The board detection scheme employed on various TI EVMs makes use of SRAM scratch space to share data read from an on-board EEPROM between the different bootloading stages. Map the associated definition that's used to locate this data into the SRAM scratch space we use on AM654x. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla --- arch/arm/mach-k3/include/mach/am6_hardware.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h index 3343233aa3..6df7631545 100644 --- a/arch/arm/mach-k3/include/mach/am6_hardware.h +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h @@ -44,4 +44,7 @@ #define CTRLMMR_LOCK_KICK1 0x0100c #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a +/* MCU SCRATCHPAD usage */ +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE + #endif /* __ASM_ARCH_AM6_HARDWARE_H */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/18] arm64: dts: k3-am654-base-board: Add I2C GPIO expander @ 0x38
The AM654 base board has a TCA9554/PCA9554-type GPIO expander on the
wkup_i2c0 bus at address 0x38 that is used to detect the presence of
daughter cards. Add a respective DTS description of this expander
to enable its use.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am654-base-board.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/k3-am654-base-board.dts
b/arch/arm/dts/k3-am654-base-board.dts
index e31411e39d..c6a595be23 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -48,4 +48,11 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0_pins_default>;
clock-frequency = <40>;
+
+ tca9554: gpio@38 {
+ compatible = "nxp,pca9554";
+ reg = <0x38>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 10/18] configs: am65x_hs_evm_a53: Enable PCA953X-type GPIO driver
Enable GPIO driver for PCA953X-compatible I2C-based I/O expander which includes support for the TCA9554/PCA9554-type expander found on the AM654 EVM base board. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Acked-by: Andrew F. Davis --- configs/am65x_hs_evm_a53_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig index 42bd90dec0..239d5efa29 100644 --- a/configs/am65x_hs_evm_a53_defconfig +++ b/configs/am65x_hs_evm_a53_defconfig @@ -57,6 +57,8 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_GPIO=y +CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_SYS_I2C_OMAP24XX=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/18] arm: dts: k3-am654-base-board: Enable wkup_i2c0 across all boot stages
To enable the use of an EEPROM-based board detection scheme we need to
be able to access the I2C bus associated with the EEPROMs across all
3 stages of U-Boot: R5 SPL, A53 SPL, and A53 U-Boot (proper). So go
ahead and add/update the wkup_i2c0 peripheral module DTS definitions
and its associated pinmux node accordingly.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am65.dtsi| 1 +
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 12
arch/arm/dts/k3-am654-base-board.dts | 15 +++
arch/arm/dts/k3-am654-r5-base-board.dts | 13 +
4 files changed, 41 insertions(+)
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 5bcf6e0693..50f4be2047 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
model = "Texas Instruments K3 AM654 SoC";
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index c802f0b2b7..eb057e7a96 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -117,6 +117,14 @@
u-boot,dm-spl;
};
+_pmx0 {
+ u-boot,dm-spl;
+
+ wkup_i2c0_pins_default {
+ u-boot,dm-spl;
+ };
+};
+
_pmx0 {
u-boot,dm-spl;
main_uart0_pins_default: main_uart0_pins_default {
@@ -189,3 +197,7 @@
pinctrl-0 = <_mmc1_pins_default>;
sdhci-caps-mask = <0x7 0x0>;
};
+
+_i2c0 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/k3-am654-base-board.dts
b/arch/arm/dts/k3-am654-base-board.dts
index af6956fdc1..e31411e39d 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -34,3 +34,18 @@
};
};
};
+
+_pmx0 {
+ wkup_i2c0_pins_default: wkup-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) /* (AC7)
WKUP_I2C0_SCL */
+ AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) /* (AD6)
WKUP_I2C0_SDA */
+ >;
+ };
+};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+};
diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts
b/arch/arm/dts/k3-am654-r5-base-board.dts
index a07038be70..1ef525ea69 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -130,6 +130,13 @@
>;
u-boot,dm-spl;
};
+
+ wkup_i2c0_pins_default: wkup-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) /* (AC7)
WKUP_I2C0_SCL */
+ AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) /* (AD6)
WKUP_I2C0_SDA */
+ >;
+ };
};
{
@@ -137,3 +144,9 @@
pinctrl-names = "default";
pinctrl-0 = <_vtt_pins_default>;
};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 17/18] configs: am65x_evm: Add support for applying overlays
This will allow for downloading and applying overlays from an MMC/SD
boot media based on the overlay_files ENV variable containing a list
of overlay files.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
configs/am65x_evm_a53_defconfig | 3 ++-
include/configs/am65x_evm.h | 9 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 2aa54706a0..e9a008d64f 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -16,7 +16,7 @@ CONFIG_DISTRO_DEFAULTS=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_TEXT_BASE=0x8008
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
@@ -80,3 +80,4 @@ CONFIG_SOC_TI=y
CONFIG_SYSRESET=y
CONFIG_SPL_SYSRESET=y
CONFIG_SYSRESET_TI_SCI=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 7e3d6a3b8f..e3dbcce0bf 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -42,6 +42,7 @@
"setenv overlay_files ${name_overlays}\0" \
"loadaddr=0x8008\0" \
"fdtaddr=0x8200\0" \
+ "overlayaddr=0x8300\0" \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0" \
"args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280\0" \
@@ -56,6 +57,14 @@
"rd_spec=-\0" \
"init_mmc=run args_all args_mmc\0" \
"get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}\0" \
+ "get_overlay_mmc=" \
+ "fdt address ${fdtaddr};" \
+ "fdt resize 0x10;" \
+ "for overlay in $overlay_files;"\
+ "do;" \
+ "load mmc ${bootpart} ${overlayaddr} ${bootdir}/${overlay};"
\
+ "fdt apply ${overlayaddr};" \
+ "done;\0" \
"get_kern_mmc=load mmc ${bootpart} ${loadaddr} "\
"${bootdir}/${name_kern}\0"
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/18] arm: dts: k3-am65: Move pinctrl nodes out of U-Boot specific dtsi
Only U-Boot specifc DT properties or overrides, must be in -u-boot.dtsi.
Pinctrl nodes does not belong here. Now that pinctrl nodes are in kernel
DT, there is no reason to be keep these in -u-boot.dtsi. Move them to
proper places so that it would ease copying DT entries from kernel DT.
Signed-off-by: Vignesh R
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am65-main.dtsi | 16 ++
arch/arm/dts/k3-am65-wakeup.dtsi | 8 +++
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 23
3 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index adcd6341e4..f7c2a60d5c 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -69,4 +69,20 @@
clock-frequency = <4800>;
current-speed = <115200>;
};
+
+ main_pmx0: pinmux@11c000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0x11c000 0x0 0x2e4>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ };
+
+ main_pmx1: pinmux@11c2e8 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0x11c2e8 0x0 0x24>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ };
};
diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
index 1f591ef8bb..1b67747dfe 100644
--- a/arch/arm/dts/k3-am65-wakeup.dtsi
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -34,6 +34,14 @@
};
};
+ wkup_pmx0: pinmux@4301c000 {
+ compatible = "pinctrl-single";
+ reg = <0x4301c000 0x118>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ };
+
wkup_uart0: serial@4230 {
compatible = "ti,am654-uart";
reg = <0x4230 0x100>;
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index f5c8253831..c802f0b2b7 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -19,22 +19,6 @@
_main{
u-boot,dm-spl;
- main_pmx0: pinmux@11c000 {
- compatible = "pinctrl-single";
- reg = <0x0 0x11c000 0x0 0x2e4>;
- #pinctrl-cells = <1>;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x>;
- };
-
- main_pmx1: pinmux@11c2e8 {
- compatible = "pinctrl-single";
- reg = <0x0 0x11c2e8 0x0 0x24>;
- #pinctrl-cells = <1>;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x>;
- };
-
sdhci0: sdhci@04F8 {
compatible = "arasan,sdhci-5.1";
reg = <0x0 0x4F8 0x0 0x1000>,
@@ -57,13 +41,6 @@
_mcu {
u-boot,dm-spl;
- wkup_pmx0: pinmux@4301c000 {
- compatible = "pinctrl-single";
- reg = <0x0 0x4301c000 0x0 0x118>;
- #pinctrl-cells = <1>;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x>;
- };
navss_mcu: navss-mcu {
compatible = "simple-bus";
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 07/18] configs: am65x_hs_evm_defconfig: Enable I2C support
Enable I2C via driver model as well as the associated set of U-Boot commands to allow us interacting with various I2C slave devices. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Acked-by: Andrew F. Davis --- configs/am65x_hs_evm_a53_defconfig | 4 configs/am65x_hs_evm_r5_defconfig | 4 2 files changed, 8 insertions(+) diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig index 9c55cd37f6..42bd90dec0 100644 --- a/configs/am65x_hs_evm_a53_defconfig +++ b/configs/am65x_hs_evm_a53_defconfig @@ -33,6 +33,7 @@ CONFIG_SPL_REMOTEPROC=y CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -56,6 +57,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_DM_MMC=y diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig index 0b12f15782..9ce7b0a2e7 100644 --- a/configs/am65x_hs_evm_r5_defconfig +++ b/configs/am65x_hs_evm_r5_defconfig @@ -37,6 +37,7 @@ CONFIG_CMD_BOOTZ=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -60,6 +61,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_TI_SCI_PROTOCOL=y CONFIG_DM_GPIO=y CONFIG_DA8XX_GPIO=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_MISC=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/18] configs: am65x_evm_a53: Enable PCA953X-type GPIO driver
Enable GPIO driver for PCA953X-compatible I2C-based I/O expander which includes support for the TCA9554/PCA9554-type expander found on the AM654 EVM base board. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index e1c7cbe7dc..3a8166d32d 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -54,6 +54,8 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_GPIO=y +CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_SYS_I2C_OMAP24XX=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 11/18] configs: am65x_evm_a53: Increase malloc pool before relocation
The malloc pool used before relocation is getting tight leading to out of memory errors doing certain DM-related calls. Since we are running the A53 SPL out of DDR let's just go ahead and bump its size as used in U-Boot proper as well as SPL (via Kconfig default value) from 8KB to 32KB. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 3a8166d32d..2aa54706a0 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_K3=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SOC_K3_AM6=y CONFIG_TARGET_AM654_A53_EVM=y CONFIG_SPL_MMC_SUPPORT=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 12/18] configs: am65x_hs_evm_a53: Increase malloc pool before relocation
The malloc pool used before relocation is getting tight leading to out of memory errors doing certain DM-related calls. Since we are running the A53 SPL out of DDR let's just go ahead and bump its size as used in U-Boot proper as well as SPL (via Kconfig default value) from 8KB to 32KB. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Acked-by: Andrew F. Davis --- configs/am65x_hs_evm_a53_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig index 239d5efa29..e74bd5de08 100644 --- a/configs/am65x_hs_evm_a53_defconfig +++ b/configs/am65x_hs_evm_a53_defconfig @@ -3,7 +3,7 @@ CONFIG_ARCH_K3=y CONFIG_TI_SECURE_DEVICE=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SOC_K3_AM6=y CONFIG_TARGET_AM654_A53_EVM=y CONFIG_SPL_MMC_SUPPORT=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 04/18] arm: dts: k3-am65: Add I2C nodes
Add I2C DT nodes
Signed-off-by: Vignesh R
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am65-main.dtsi | 44
arch/arm/dts/k3-am65-mcu.dtsi| 11
arch/arm/dts/k3-am65-wakeup.dtsi | 11
arch/arm/dts/k3-am65.dtsi| 6 +
4 files changed, 72 insertions(+)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index f7c2a60d5c..9164348396 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -85,4 +85,48 @@
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x>;
};
+
+ main_i2c0: i2c@200 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x200 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 110 1>;
+ power-domains = <_pds 110>;
+ };
+
+ main_i2c1: i2c@201 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x201 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 111 1>;
+ power-domains = <_pds 111>;
+ };
+
+ main_i2c2: i2c@202 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x202 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 112 1>;
+ power-domains = <_pds 112>;
+ };
+
+ main_i2c3: i2c@203 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x203 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 113 1>;
+ power-domains = <_pds 113>;
+ };
};
diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index 8c611d16df..1fd027748e 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -15,4 +15,15 @@
clock-frequency = <9600>;
current-speed = <115200>;
};
+
+ mcu_i2c0: i2c@40b0 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x40b0 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 114 1>;
+ power-domains = <_pds 114>;
+ };
};
diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
index 1b67747dfe..1f85006f55 100644
--- a/arch/arm/dts/k3-am65-wakeup.dtsi
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -51,4 +51,15 @@
clock-frequency = <4800>;
current-speed = <115200>;
};
+
+ wkup_i2c0: i2c@4212 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x4212 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 115 1>;
+ power-domains = <_pds 115>;
+ };
};
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 3d4bf369d0..5bcf6e0693 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -22,6 +22,12 @@
serial2 = _uart0;
serial3 = _uart1;
serial4 = _uart2;
+ i2c0 = _i2c0;
+ i2c1 = _i2c0;
+ i2c2 = _i2c0;
+ i2c3 = _i2c1;
+ i2c4 = _i2c2;
+ i2c5 = _i2c3;
};
chosen { };
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 14/18] ti: common: am6: Add support for board description EEPROM
The AM654x EVM based on the TI K3 family of SoCs have an updated board
detection EEPROM structure, now comprising variable-sized TLV-type
records, containing a superset of what is already being provided on
earlier platforms such as DRA7. Add basic support for parsing the new
data structures contained on the base board into the common TI EEPROM
structure while also providing infrastructure that can be used later on
to parse data from additional EEPROMs such as the ones that are used on
daughtercards for this platform.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
board/ti/common/board_detect.c | 214 +
board/ti/common/board_detect.h | 194 ++
2 files changed, 408 insertions(+)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index e258e22f37..fea39f21e8 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -284,6 +285,191 @@ int __maybe_unused ti_i2c_eeprom_dra7_get(int bus_addr,
int dev_addr)
return 0;
}
+static int ti_i2c_eeprom_am6_parse_record(struct ti_am6_eeprom_record *record,
+ struct ti_am6_eeprom *ep,
+ char **mac_addr,
+ u8 mac_addr_max_cnt,
+ u8 *mac_addr_cnt)
+{
+ switch (record->header.id) {
+ case TI_AM6_EEPROM_RECORD_BOARD_INFO:
+ if (record->header.len != sizeof(record->data.board_info))
+ return -EINVAL;
+
+ if (!ep)
+ break;
+
+ /* Populate (and clean, if needed) the board name */
+ strlcpy(ep->name, record->data.board_info.name,
+ sizeof(ep->name));
+ ti_eeprom_string_cleanup(ep->name);
+
+ /* Populate selected other fields from the board info record */
+ strlcpy(ep->version, record->data.board_info.version,
+ sizeof(ep->version));
+ strlcpy(ep->software_revision,
+ record->data.board_info.software_revision,
+ sizeof(ep->software_revision));
+ strlcpy(ep->serial, record->data.board_info.serial,
+ sizeof(ep->serial));
+ break;
+ case TI_AM6_EEPROM_RECORD_MAC_INFO:
+ if (record->header.len != sizeof(record->data.mac_info))
+ return -EINVAL;
+
+ if (!mac_addr || !mac_addr_max_cnt)
+ break;
+
+ *mac_addr_cnt = ((record->data.mac_info.mac_control &
+TI_AM6_EEPROM_MAC_ADDR_COUNT_MASK) >>
+TI_AM6_EEPROM_MAC_ADDR_COUNT_SHIFT) + 1;
+
+ /*
+* The EEPROM can (but may not) hold a very large amount
+* of MAC addresses, by far exceeding what we want/can store
+* in the common memory array, so only grab what we can fit.
+* Note that a value of 0 means 1 MAC address, and so on.
+*/
+ *mac_addr_cnt = min(*mac_addr_cnt, mac_addr_max_cnt);
+
+ memcpy(mac_addr, record->data.mac_info.mac_addr,
+ *mac_addr_cnt * TI_EEPROM_HDR_ETH_ALEN);
+ break;
+ case 0x00:
+ /* Illegal value... Fall through... */
+ case 0xFF:
+ /* Illegal value... Something went horribly wrong... */
+ return -EINVAL;
+ default:
+ pr_warn("%s: Ignoring record id %u\n", __func__,
+ record->header.id);
+ }
+
+ return 0;
+}
+
+int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int dev_addr,
+struct ti_am6_eeprom *ep,
+char **mac_addr,
+u8 mac_addr_max_cnt,
+u8 *mac_addr_cnt)
+{
+ struct udevice *dev;
+ struct udevice *bus;
+ unsigned int eeprom_addr;
+ struct ti_am6_eeprom_record_board_id board_id;
+ struct ti_am6_eeprom_record record;
+ int rc;
+
+ /* Initialize with a known bad marker for i2c fails.. */
+ memset(ep, 0, sizeof(*ep));
+ ep->header = TI_DEAD_EEPROM_MAGIC;
+
+ /* Read the board ID record which is always the first EEPROM record */
+ rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC,
+ sizeof(board_id), (uint8_t *)_id);
+ if (rc)
+ return rc;
+
+ if (board_id.header.id != TI_AM6_EEPROM_RECORD_BOARD_ID) {
+ pr_err("%s: Invalid board ID record!\n", __func__);
+ return -EINVAL;
+ }
+
+ /* Establish DM
[U-Boot] [PATCH v2 01/18] i2c: omap24xx_i2c: Adapt driver to support K3 devices
From: Vignesh R K3 devices have I2C IP that is same as OMAP2+ family. Allow driver to be compiled for ARCH_K3. Signed-off-by: Vignesh R Signed-off-by: Andreas Dannenberg Reviewed-by: Heiko Schocher Reviewed-by: Lokesh Vutla --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 095a9bc6a4..4772db3837 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -330,7 +330,7 @@ endif config SYS_I2C_OMAP24XX bool "TI OMAP2+ I2C driver" - depends on ARCH_OMAP2PLUS + depends on ARCH_OMAP2PLUS || ARCH_K3 help Add support for the OMAP2+ I2C driver. -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 18/18] configs: am65x_hs_evm: Add support for applying overlays
This will allow for downloading and applying overlays from an MMC/SD
boot media based on the overlay_files ENV variable containing a list
of overlay files.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
configs/am65x_hs_evm_a53_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_hs_evm_a53_defconfig
b/configs/am65x_hs_evm_a53_defconfig
index e74bd5de08..270c783916 100644
--- a/configs/am65x_hs_evm_a53_defconfig
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -19,7 +19,7 @@ CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_TEXT_BASE=0x8008
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
@@ -83,3 +83,4 @@ CONFIG_SOC_TI=y
CONFIG_SYSRESET=y
CONFIG_SPL_SYSRESET=y
CONFIG_SYSRESET_TI_SCI=y
+CONFIG_OF_LIBFDT_OVERLAY=y
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 06/18] configs: am65x_evm_defconfig: Enable I2C support
Enable I2C via driver model as well as the associated set of U-Boot commands to allow us interacting with various I2C slave devices. Signed-off-by: Andreas Dannenberg Signed-off-by: Vignesh R Reviewed-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 4 configs/am65x_evm_r5_defconfig | 4 2 files changed, 8 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 41cf0100fa..e1c7cbe7dc 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_REMOTEPROC=y CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -53,6 +54,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_DM_MMC=y diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig index 3814872ec7..f832491fd3 100644 --- a/configs/am65x_evm_r5_defconfig +++ b/configs/am65x_evm_r5_defconfig @@ -35,6 +35,7 @@ CONFIG_CMD_BOOTZ=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -58,6 +59,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_TI_SCI_PROTOCOL=y CONFIG_DM_GPIO=y CONFIG_DA8XX_GPIO=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_MISC=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 00/18] Add EEPROM-based board detect support for TI K3 SoCs
This series adds the pieces needed to fully configure the TI AM654x EVM and its associated (optional) daughtercards using a GPIO-based card presence detection scheme. Changes since initial submission: - Re-based onto latest 'master' branch - Collected all review tags - Re-tested Andreas Dannenberg (16): arm: dts: k3-am65: Move pinctrl nodes out of U-Boot specific dtsi arm: dts: k3-am65: Add I2C nodes arm: dts: k3-am654-base-board: Enable wkup_i2c0 across all boot stages configs: am65x_evm_defconfig: Enable I2C support configs: am65x_hs_evm_defconfig: Enable I2C support arm64: dts: k3-am654-base-board: Add I2C GPIO expander @ 0x38 configs: am65x_evm_a53: Enable PCA953X-type GPIO driver configs: am65x_hs_evm_a53: Enable PCA953X-type GPIO driver configs: am65x_evm_a53: Increase malloc pool before relocation configs: am65x_hs_evm_a53: Increase malloc pool before relocation arm: K3: am654: Map common EEPROM data into SRAM scratch space ti: common: am6: Add support for board description EEPROM ti: common: am6: Add support for setting MAC addresses board: ti: am654: Use EEPROM-based board detection configs: am65x_evm: Add support for applying overlays configs: am65x_hs_evm: Add support for applying overlays Vignesh R (2): i2c: omap24xx_i2c: Adapt driver to support K3 devices arm: omap_i2c: Remove unwanted header file inclusion arch/arm/dts/k3-am65-main.dtsi | 60 + arch/arm/dts/k3-am65-mcu.dtsi| 11 + arch/arm/dts/k3-am65-wakeup.dtsi | 19 ++ arch/arm/dts/k3-am65.dtsi| 7 + arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 35 +-- arch/arm/dts/k3-am654-base-board.dts | 22 ++ arch/arm/dts/k3-am654-r5-base-board.dts | 13 + arch/arm/include/asm/omap_i2c.h | 2 - arch/arm/mach-k3/am6_init.c | 4 + arch/arm/mach-k3/include/mach/am6_hardware.h | 3 + arch/arm/mach-k3/include/mach/sys_proto.h| 2 + board/ti/am65x/Kconfig | 7 + board/ti/am65x/evm.c | 241 ++ board/ti/common/board_detect.c | 246 +++ board/ti/common/board_detect.h | 206 configs/am65x_evm_a53_defconfig | 11 +- configs/am65x_evm_r5_defconfig | 4 + configs/am65x_hs_evm_a53_defconfig | 11 +- configs/am65x_hs_evm_r5_defconfig| 4 + drivers/i2c/Kconfig | 2 +- include/configs/am65x_evm.h | 18 +- 21 files changed, 892 insertions(+), 36 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] sound: Add sound support for Nyan
Simon, -Original Message- From: Simon Glass Sent: Wednesday, May 22, 2019 6:25 AM To: U-Boot Mailing List Cc: Jonathan Hunter ; Stephen Warren ; Stephen Warren ; Tom Warren Subject: Re: [PATCH v2 0/7] sound: Add sound support for Nyan Hi Tom, On Mon, 1 Apr 2019 at 14:38, Simon Glass wrote: > > This series adds sound support for Nyan. It allows simple beeps to be > generated in U-Boot. This requires the addition of an I2S driver, an > audio hub driver and a sound driver to pull things together. An > existing audio codec (MAX98090) is used. > > Changes in v2: > - Fix 'I2C' typo > - Drop setting of slot_ctrl from i2s_tx_init() > > Simon Glass (7): > tegra: Correct tegra124 clock name > tegra: Add a delay in clock_start_periph_pll() > tegra: sound: Add an audio hub driver > tegra: sound: Add an I2S driver > sound: tegra: Add a sound driver > tegra: nyan-big: Enable sound > tegra: nyan: Add a README > > arch/arm/include/asm/arch-tegra/tegra_ahub.h | 475 > +++ arch/arm/include/asm/arch-tegra/tegra_i2s.h | 206 > > arch/arm/mach-tegra/clock.c | 1 + > arch/arm/mach-tegra/tegra124/clock.c | 2 +- > board/nvidia/nyan-big/README | 18 + > board/nvidia/nyan-big/nyan-big.c | 2 +- > configs/nyan-big_defconfig | 7 + > drivers/sound/Kconfig| 9 + > drivers/sound/Makefile | 1 + > drivers/sound/tegra_ahub.c | 256 ++ > drivers/sound/tegra_i2s.c| 123 + > drivers/sound/tegra_i2s_priv.h | 29 ++ > drivers/sound/tegra_sound.c | 100 > 13 files changed, 1227 insertions(+), 2 deletions(-) create mode > 100644 arch/arm/include/asm/arch-tegra/tegra_ahub.h > create mode 100644 arch/arm/include/asm/arch-tegra/tegra_i2s.h > create mode 100644 board/nvidia/nyan-big/README create mode 100644 > drivers/sound/tegra_ahub.c create mode 100644 > drivers/sound/tegra_i2s.c create mode 100644 > drivers/sound/tegra_i2s_priv.h create mode 100644 > drivers/sound/tegra_sound.c > This series still seems to be in limbo. How can this get applied? Yeah, sorry, I forgot about these. I'll try to get them applied this week. Tom Regards, Simon --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
On 5/22/19 5:15 PM, Tom Rini wrote: > On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote: >> On Tue, May 21, 2019 at 11:34 PM Tom Rini wrote: >> >>> As came up in another thread, CONFIG_MMC_TINY may be more widely useable >>> and should help with space. >> >> How it can be used exactly? >> >> I tried it like this: >> >> --- a/configs/mx6sabresd_defconfig >> +++ b/configs/mx6sabresd_defconfig >> @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y >> CONFIG_SPL_LIBGENERIC_SUPPORT=y >> CONFIG_SYS_MALLOC_F_LEN=0x4000 >> CONFIG_TARGET_MX6SABRESD=y >> -CONFIG_SPL_MMC_SUPPORT=y >> CONFIG_SPL_SERIAL_SUPPORT=y >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_SPL=y >> @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y >> CONFIG_USB_ETHER_ASIX=y >> CONFIG_DM_VIDEO=y >> CONFIG_VIDEO_IPUV3=y >> +CONFIG_SPL_MMC_TINY=y >> >> , but the board does not boot: >> >> U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300) >> SPL: Unsupported Boot Device! >> SPL: failed to boot from all boot devices >> ### ERROR ### Please RESET the board ### > > Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how > to configure / use it, in the other thread. Look at what the CI20 does ? That board boots from SD and uses the TINY stuff. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote: > On Tue, May 21, 2019 at 11:34 PM Tom Rini wrote: > > > As came up in another thread, CONFIG_MMC_TINY may be more widely useable > > and should help with space. > > How it can be used exactly? > > I tried it like this: > > --- a/configs/mx6sabresd_defconfig > +++ b/configs/mx6sabresd_defconfig > @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > CONFIG_SYS_MALLOC_F_LEN=0x4000 > CONFIG_TARGET_MX6SABRESD=y > -CONFIG_SPL_MMC_SUPPORT=y > CONFIG_SPL_SERIAL_SUPPORT=y > CONFIG_NR_DRAM_BANKS=1 > CONFIG_SPL=y > @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y > CONFIG_DM_VIDEO=y > CONFIG_VIDEO_IPUV3=y > +CONFIG_SPL_MMC_TINY=y > > , but the board does not boot: > > U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300) > SPL: Unsupported Boot Device! > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how to configure / use it, in the other thread. -- 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] Making U-Boot smaller
On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote: > cc: Yamada-san > > I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which > would point out the culprit configs. This is hardly achievable, but > looks good on the paper! > > CONFIG FILE SIZE > -- > CONFIG_FEATURE_A10.7Mi 37.1% > CONFIG_FEATURE_B5.39Mi 18.6% > CONFIG_FEATURE_C4.48Mi 15.5% > CONFIG_FEATURE_D1.86Mi 6.4% > CONFIG_FEATURE_E1.67Mi 5.8% > CONFIG_FEATURE_F1.61Mi 5.6% > CONFIG_FEATURE_G 856Ki 2.9% > CONFIG_FEATURE_H 470Ki 1.6% > > TOTAL 28.9Mi 100.0% > > [1] https://github.com/google/bloaty This is relatively easy to do today, with buildman and a local commit to enable/disable CONFIG_FEATURE_A. -- 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] [PATCHv5 0/8] pci: Add PCIe Gen4 controller driver for NXP Layerscape SoCs
> -Original Message- > From: Prabhakar Kushwaha > Sent: 2019年5月22日 20:33 > To: Z.q. Hou ; u-boot@lists.denx.de; > albert.u.b...@aribaud.net; Priyanka Jain ; York Sun > ; sriram.d...@nxp.com; > yamada.masah...@socionext.com; Mingkai Hu ; M.h. > Lian ; bmeng...@gmail.com > Subject: RE: [PATCHv5 0/8] pci: Add PCIe Gen4 controller driver for NXP > Layerscape SoCs > > > > -Original Message- > > From: Z.q. Hou > > Sent: Monday, April 8, 2019 3:45 PM > > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain > > ; York Sun ; > > sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar > Kushwaha > > ; Mingkai Hu ; > M.h. > > Lian ; bmeng...@gmail.com > > Cc: Z.q. Hou > > Subject: [PATCHv5 0/8] pci: Add PCIe Gen4 controller driver for NXP > > Layerscape SoCs > > > > From: Hou Zhiqiang > > > > Add PCIe Gen4 driver for the NXP Layerscape series SoCs. > > Splited the patches of adding MRRS and MPS accessors from this thread. > > > > Hou Zhiqiang (8): > > armv8: layerscape: use PCIe address macro to precompile PCIe MMU > entry > > armv8: fsl-layerscpae: correct the PCIe controllers' region size > > armv8: lx2160a: add MMU table entries for PCIe > > pci: Add PCIe Gen4 controller driver for NXP Layerscape SoCs > > kconfig: add dependency PCIE_LAYERSCAPE_GEN4 for > FSL_PCIE_COMPAT > > pci: ls_pcie_g4: add device tree fixups for PCI Stream IDs > > armv8: lx2160a: add PCIe controller DT nodes > > armv8: lx2160a: enable PCIe support > > > > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 2 +- > > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 16 +- > > arch/arm/dts/fsl-lx2160a.dtsi | 85 +++ > > .../arm/include/asm/arch-fsl-layerscape/cpu.h | 9 + > > .../asm/arch-fsl-layerscape/immap_lsch3.h | 14 +- > > configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 5 + > > configs/lx2160aqds_tfa_defconfig | 6 + > > configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 7 +- > > configs/lx2160ardb_tfa_defconfig | 6 + > > drivers/pci/Kconfig | 8 + > > drivers/pci/Makefile | 2 + > > drivers/pci/pcie_layerscape_gen4.c| 572 > ++ > > drivers/pci/pcie_layerscape_gen4.h| 264 > > drivers/pci/pcie_layerscape_gen4_fixup.c | 249 > > 14 files changed, 1241 insertions(+), 4 deletions(-) create mode > > 100644 drivers/pci/pcie_layerscape_gen4.c > > create mode 100644 drivers/pci/pcie_layerscape_gen4.h > > create mode 100644 drivers/pci/pcie_layerscape_gen4_fixup.c > > use PCIe address macro for precompile PCIe MMU entry --> modified patch > put all CONFIG_SYS_PCIE4_PHYS_ADDR reference to #ifdef > CONFIG_SYS_PCIE4_PHYS_ADDR. > > This patch-series has been applied to fsl-qoriq master, awaiting upstream Prabhakar, thanks a lot! - Zhiqiang > > --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
On Tue, May 21, 2019 at 11:34 PM Tom Rini wrote: > As came up in another thread, CONFIG_MMC_TINY may be more widely useable > and should help with space. How it can be used exactly? I tried it like this: --- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_MX6SABRESD=y -CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y +CONFIG_SPL_MMC_TINY=y , but the board does not boot: U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300) SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Making U-Boot smaller
cc: Yamada-san
I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which
would point out the culprit configs. This is hardly achievable, but
looks good on the paper!
CONFIG FILE SIZE
--
CONFIG_FEATURE_A10.7Mi 37.1%
CONFIG_FEATURE_B5.39Mi 18.6%
CONFIG_FEATURE_C4.48Mi 15.5%
CONFIG_FEATURE_D1.86Mi 6.4%
CONFIG_FEATURE_E1.67Mi 5.8%
CONFIG_FEATURE_F1.61Mi 5.6%
CONFIG_FEATURE_G 856Ki 2.9%
CONFIG_FEATURE_H 470Ki 1.6%
TOTAL 28.9Mi 100.0%
[1] https://github.com/google/bloaty
--
Best regards,
Eugeniu
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
