Re: [U-Boot] [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to incorporate 4 byte commands
> -Original Message- > From: U-Boot On Behalf Of Schrempf Frieder > Sent: Tuesday, April 30, 2019 1:14 PM > To: Vignesh Raghavendra ; Rajat Srivastava > ; u-boot@lists.denx.de; ja...@openedev.com > Subject: [EXT] Re: [U-Boot] [PATCH 2/2] fsl_qspi: Improve QSPI driver to > incorporate 4 byte commands > > Caution: EXT Email > > Hi, > > On 26.04.19 06:58, Vignesh Raghavendra wrote: > > > > > > On 25/04/19 5:20 PM, Rajat Srivastava wrote: > >> > >> > >>> -Original Message- > >>> From: Vignesh Raghavendra > >>> Sent: Wednesday, April 24, 2019 10:17 PM > >>> To: Rajat Srivastava ; > >>> u-boot@lists.denx.de; ja...@openedev.com > >>> Cc: Ashish Kumar > >>> Subject: [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to > >>> incorporate 4 byte commands > >>> > >>> Caution: EXT Email > >>> > >>> On 24-Apr-19 6:10 PM, Rajat Srivastava wrote: > Signed-off-by: Ashish Kumar > Signed-off-by: Rajat Srivastava > >>> > >>> Commit message is missing. > >> > >> I'll add proper commit message in the next patch version. > >> > >>> But from $patch subject, I infer that $patch is adding new feature > >>> and not actually fixing something broken? > >> > >> Earlier the framework was designed to work for only 3-byte opcodes > >> but our controller supports flashes of size greater than 16 MB. As a > >> workaround, FSL QSPI driver used to explicitly send 4-byte opcodes > >> for 3-byte opcodes sent by framework to the flash. Also there used to > >> exist a temporary patch for framework which never got accepted In > upstream. > >> Now the new framework supports 4-byte opcodes and FSL QSPI driver > >> needs correction. I am not introducing any new feature. I am just > >> fixing the driver to suit the current framework. > >> > > > > With SPL_FLASH_BAR set fsl_qspi driver should never see 4 byte opcodes > > and should work like it did before. I guess you are disabling SPI_FLASH_BAR? > > > > Please add all details to the commit message and I recommend you to > > move the driver over to spi-mem as soon as possible. Else you would > > have to keep handling new opcodes in your driver as and when spi-nor-core > changes. > > > > Regards > > Vignesh > > > >> Please let me know your feedback. > >> > >> Regards > >> Rajat > >> > >>> If so, you should move the driver over to use spi-mem APIs instead > >>> of adding more features and hard coding more flash specific commands in > the driver. > >>> This makes driver duplicate more of spi-nor core code. I discourage > >>> adding new features w/o moving driver over to spi-mem. IMHO, > >>> converting the driver would not be a huge effort. And I believe its > >>> already > done in kernel. > > I started moving the driver to spi-mem, by porting the kernel driver over to > U- > Boot. I still have some Kconfig dependency problem for the > LS2081 platform (CONFIG_SPI_MEM is not enabled implicitly), that needs to > be solved, otherwise it should be more or less ready. Hi Frieder, What is the change, it seems it is moving the driver from Linux as it is to uboot ? I am not sure how stable is the current Linux driver, since it is not yet tested by FSL/NXP system test team. Last time I tested the current Linux driver(QSPI) it was functional in only 1-1-1 mode. Moving to u-boot may not be good idea at this point of time. How do you plan to cater CONFIG_SPI_BAR change in uboot now. Some old board still uses flash that supports CONFIG_SPI_BAR. Me and Rajat have recently posted patches to fix current u-boot driver to be functional with new frame work pushed by Vignesh, and it serves all the current supported board with and without CONFIG_SPI_BAR. May be spi-nxp-fspi.c can be a good starting point, but then again I not sure how booting from serial-nand will be taken care in that case. Regards Ashish > > For anyone who wants to check/test the current state, look here: [1] > > Regards, > Frieder > > [1]: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Ffschrempf%2Fu- > boot%2Fcommits%2Ffsl_qspi_spimem_portdata=02%7C01%7CAshish.K > umar%40nxp.com%7C459c6d89b8b748c928ca08d6cd3fa6cd%7C686ea1d3bc > 2b4c6fa92cd99c5c301635%7C0%7C0%7C636922070665346047sdata > =8HplTAZYeEaBrXZd38h4hgT7hLRixjobx%2ByCjL%2FjJjc%3Dreserved=0 > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.de > nx.de%2Flistinfo%2Fu- > bootdata=02%7C01%7CAshish.Kumar%40nxp.com%7C459c6d89b8b74 > 8c928ca08d6cd3fa6cd%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 > %7C636922070665346047sdata=sk6GB%2BMeEKjqR5BR5K9PX6yYayC > nyDUG69LTWl05xlM%3Dreserved=0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Wed, May 01, 2019 at 12:56:30AM +, Joe Hershberger wrote: > On Tue, Apr 30, 2019 at 4:29 PM Tom Rini wrote: > > > > On Tue, Apr 30, 2019 at 09:15:33PM +, Joe Hershberger wrote: > > > On Tue, Mar 19, 2019 at 5:41 PM Tom Rini wrote: > > > > > > > > On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > These patches passed the CI build here: > > > > > https://travis-ci.org/jhershbe/u-boot/builds/501807294 > > > > > > > > > > The following changes since commit > > > > > 2e8092d94f40a5692baf3ec768ce3216a7bf032a: > > > > > > > > > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 > > > > > 15:48:57 -0400) > > > > > > > > > > are available in the git repository at: > > > > > > > > > > > > > > > git://git.denx.de/u-boot-net.git master > > > > > > > > > > for you to fetch changes up to > > > > > 85f05f72bacc2d047731fc64801e4f6b34cf: > > > > > > > > > > net: phy: aquantia: Set only autoneg on in register 4.c441 > > > > > (2019-03-12 13:13:37 -0500) > > > > > > > > > > > > > NAK. One of: > > > > The first bad commit could be any of: > > > > 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1 > > > > 8860e1563f38d16f7ae29053018cd445c0fa111d > > > > ebb5027d69196dd83fd0fa5bd91fca07acfd77be > > > > 09e0a36497c84273e5b22488d5af01bf0ba17469 > > > > 841b9df209e37fe1bfefa5f44e837a0ad497443f > > > > 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447 > > > > 7aadf5134f2f5771689d0657b69875d0a464859d > > > > d35488518f3c16d305092c816a5129f45a0b62d7 > > > > Breaks am335x_evm ethernet: > > > > 18:39:52 => => dhcp > > > > 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to > > > > complete... done > > > > 18:39:52 link up on port 0, speed 1000, full duplex > > > > 18:39:52 BOOTP broadcast 1 > > > > 18:39:52 BOOTP broadcast 2 > > > > 18:39:52 BOOTP broadcast 3 > > > > 18:39:52 BOOTP broadcast 4 > > > > 18:39:52 BOOTP broadcast 5 > > > > 18:39:52 BOOTP broadcast 6 > > > > 18:39:52 BOOTP broadcast 7 > > > > 18:39:52 BOOTP broadcast 8 > > > > 18:39:52 BOOTP broadcast 9 > > > > 18:39:52 BOOTP broadcast 10 > > > > 18:39:52 BOOTP broadcast 11 > > > > 18:39:52 BOOTP broadcast 12 > > > > 18:39:52 BOOTP broadcast 13 > > > > 18:39:52 BOOTP broadcast 14 > > > > 18:39:52 BOOTP broadcast 15 > > > > 18:39:52 BOOTP broadcast 16 > > > > 18:39:52 BOOTP broadcast 17 > > > > > > I rebased the series on the current master and I can't reproduce this > > > dhcp issue. On the original series I saw broken DHCP only with "net: > > > phy: micrel: Use correct skew values on KSZ9021" which doesn't make > > > any sense because that phy is not used on BBB and isn't even compiled > > > in. Also, the issue doesn't reproduce when the next patch is applied. > > > Even that oddity doesn't happen after the rebase. > > > > > > Also the SPL for boneblack is too big to build with some of the > > > patches in this series now, so I'm not sure how that should be > > > handled. > > > > Drop those parts for now I guess and we'll have to look harder at them > > stand-alone? And I assume you mean am335x_boneblack_vboot is too large? > > Or am335x_evm itself? Thanks! > > Meaning the SPL part of am335x_evm target fails by a few hundred bytes. I need to grab the series that shaves a few hundred bytes I think then from SPL for am335x. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Tue, Apr 30, 2019 at 4:29 PM Tom Rini wrote: > > On Tue, Apr 30, 2019 at 09:15:33PM +, Joe Hershberger wrote: > > On Tue, Mar 19, 2019 at 5:41 PM Tom Rini wrote: > > > > > > On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote: > > > > > > > Hi Tom, > > > > > > > > These patches passed the CI build here: > > > > https://travis-ci.org/jhershbe/u-boot/builds/501807294 > > > > > > > > The following changes since commit > > > > 2e8092d94f40a5692baf3ec768ce3216a7bf032a: > > > > > > > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 > > > > 15:48:57 -0400) > > > > > > > > are available in the git repository at: > > > > > > > > > > > > git://git.denx.de/u-boot-net.git master > > > > > > > > for you to fetch changes up to 85f05f72bacc2d047731fc64801e4f6b34cf: > > > > > > > > net: phy: aquantia: Set only autoneg on in register 4.c441 > > > > (2019-03-12 13:13:37 -0500) > > > > > > > > > > NAK. One of: > > > The first bad commit could be any of: > > > 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1 > > > 8860e1563f38d16f7ae29053018cd445c0fa111d > > > ebb5027d69196dd83fd0fa5bd91fca07acfd77be > > > 09e0a36497c84273e5b22488d5af01bf0ba17469 > > > 841b9df209e37fe1bfefa5f44e837a0ad497443f > > > 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447 > > > 7aadf5134f2f5771689d0657b69875d0a464859d > > > d35488518f3c16d305092c816a5129f45a0b62d7 > > > Breaks am335x_evm ethernet: > > > 18:39:52 => => dhcp > > > 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to > > > complete... done > > > 18:39:52 link up on port 0, speed 1000, full duplex > > > 18:39:52 BOOTP broadcast 1 > > > 18:39:52 BOOTP broadcast 2 > > > 18:39:52 BOOTP broadcast 3 > > > 18:39:52 BOOTP broadcast 4 > > > 18:39:52 BOOTP broadcast 5 > > > 18:39:52 BOOTP broadcast 6 > > > 18:39:52 BOOTP broadcast 7 > > > 18:39:52 BOOTP broadcast 8 > > > 18:39:52 BOOTP broadcast 9 > > > 18:39:52 BOOTP broadcast 10 > > > 18:39:52 BOOTP broadcast 11 > > > 18:39:52 BOOTP broadcast 12 > > > 18:39:52 BOOTP broadcast 13 > > > 18:39:52 BOOTP broadcast 14 > > > 18:39:52 BOOTP broadcast 15 > > > 18:39:52 BOOTP broadcast 16 > > > 18:39:52 BOOTP broadcast 17 > > > > I rebased the series on the current master and I can't reproduce this > > dhcp issue. On the original series I saw broken DHCP only with "net: > > phy: micrel: Use correct skew values on KSZ9021" which doesn't make > > any sense because that phy is not used on BBB and isn't even compiled > > in. Also, the issue doesn't reproduce when the next patch is applied. > > Even that oddity doesn't happen after the rebase. > > > > Also the SPL for boneblack is too big to build with some of the > > patches in this series now, so I'm not sure how that should be > > handled. > > Drop those parts for now I guess and we'll have to look harder at them > stand-alone? And I assume you mean am335x_boneblack_vboot is too large? > Or am335x_evm itself? Thanks! Meaning the SPL part of am335x_evm target fails by a few hundred bytes. > -- > Tom > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)
On Tue, Apr 30, 2019 at 11:25 AM Simon Goldschmidt wrote: > > Am 18.04.2019 um 23:08 schrieb Julius Werner: > > This patch adds support for compressing non-kernel image nodes in a FIT > > image (kernel nodes could already be compressed previously). This can > > reduce the size of FIT images and therefore improve boot times > > (especially when an image bundles many different kernel FDTs). The > > images will automatically be decompressed on load. > > > > This patch does not support extracting compatible strings from > > compressed FDTs, so it's not very helpful in conjunction with > > CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments > > that select the configuration to load explicitly. > > > > Signed-off-by: Julius Werner > > --- > > common/image-fit.c | 83 +++--- > > 1 file changed, 49 insertions(+), 34 deletions(-) > > > > diff --git a/common/image-fit.c b/common/image-fit.c > > index ac901e131c..006e828b79 100644 > > --- a/common/image-fit.c > > +++ b/common/image-fit.c > > @@ -22,6 +22,7 @@ > > DECLARE_GLOBAL_DATA_PTR; > > #endif /* !USE_HOSTCC*/ > > > > +#include > > #include > > #include > > #include > > @@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void > > *fdt) > > kfdt_name); > > continue; > > } > > + > > + if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) { > > + debug("Can't extract compat from \"%s\" > > (compressed)\n", > > + kfdt_name); > > + continue; > > + } > > + > > What's this block good for in this patch? Looks like it belongs to 2/2? This is necessary because I'm removing the (image_type == IH_TYPE_FLATDT && !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) check below. Previously, this function would just always hard fail with compressed FDTs. With this patch, compressed FDTs can be loaded, but they can't be used for compat string matching -- that's why I need to add this check here to prevent it. You can still use compressed FDTs when selecting a configuration explicitly (e.g. bootm 0x100#conf@1). The next patch will then add another feature that makes it possible to have compat string matching with compressed FDTs. > > > /* > >* Get a pointer to this configuration's fdt. > >*/ > > @@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong > > addr, > > const char *fit_uname_config; > > const char *fit_base_uname_config; > > const void *fit; > > - const void *buf; > > + void *buf; > > + void *loadbuf; > > size_t size; > > int type_ok, os_ok; > > - ulong load, data, len; > > - uint8_t os; > > + ulong load, load_end, data, len; > > + uint8_t os, comp; > > #ifndef USE_HOSTCC > > uint8_t os_arch; > > #endif > > @@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong > > addr, > > images->os.arch = os_arch; > > #endif > > > > - if (image_type == IH_TYPE_FLATDT && > > - !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) { > > - puts("FDT image is compressed"); > > - return -EPROTONOSUPPORT; > > - } > > - > > bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL); > > type_ok = fit_image_check_type(fit, noffset, image_type) || > > fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) || > > @@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong > > addr, > > bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK); > > > > /* get image data address and length */ > > - if (fit_image_get_data_and_size(fit, noffset, , )) { > > + if (fit_image_get_data_and_size(fit, noffset, > > + (const void **), )) { > > printf("Could not find %s subimage data!\n", prop_name); > > bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA); > > return -ENOENT; > > @@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong > > addr, > > > > #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS) > > /* perform any post-processing on the image data */ > > - board_fit_image_post_process((void **), ); > > + board_fit_image_post_process(, ); > > #endif > > > > len = (ulong)size; > > > > - /* verify that image data is a proper FDT blob */ > > - if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) { > > - puts("Subimage data is not a FDT"); > > - return -ENOEXEC; > > - } > > - > > bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK); > > > > - /* > > - * Work-around for eldk-4.2 which gives this warning if we try to > > - * cast in the unmap_sysmem() call: > > - * warning: initialization
Re: [U-Boot] [RESEND PATCH 0/3] arm: Introduce writel/readl_relaxed accessors
On 29/04/2019 18:16, Jagan Teki wrote: Hi, > On Sun, Feb 10, 2019 at 9:49 PM Andre Przywara wrote: >> >> Hi, this is a resend of what I posted some weeks ago, just adding the >> missing Signed-off-by: in patch 2/3, as pointed out by Philipp. I used >> the opportunity to add his Reviewed-by: tags on the first two patches. >> (Many thanks for that!) The rest is unchanged. >> --- >> >> Admittedly this is the long way round to solve some nasty SPL code size >> problem, but it looked beneficial to others as well, so here we go: >> >> arch/arm/include/asm/io.h looks like it's been around since the dawn of >> time, and was more or less blindly copied from Linux. >> We don't use and don't need most of the definitions, and mainline Linux >> got rid of them anyway, so patch 1/3 cleans up this header file to >> just contain what we need in U-Boot. >> >> Patch 2/3 introduces readl/writel_relaxed accessors, which are cheaper, >> but more importantly save one (barrier) instruction per accessor. This >> helps to bring down code size, since especially DRAM controller inits in >> SPLs tend to do a lot of MMIO. >> >> Consequently patch 3/3 introduces them in the Allwinner H6 DRAM driver, >> which reduces the SPL size by a whopping 2KB, due to a twist: >> The AArch64 exception table needs to be 2KB aligned, but we don't do >> anything special about it the linker script. So depending on where the >> code before the vectors ends, we have potentially large padding: >> At the moment this last address is 0x1824 for the H6, so the vectors can >> only start at 0x2000. By reducing the code size before the vectors by just >> (at least) 9 instructions, the vectors start at 0x1800 and we save most of >> the padding. >> >> I understand that the proper solution is to fill the gap before the vectors >> with code instead of NOPs, but I couldn't find any obvious way doing this >> in the linker script. If anyone has any idea here, I am all ears. >> >> Cheers, >> Andre. >> >> Andre Przywara (3): >> arm: clean up asm/io.h >> arm: introduce _relaxed MMIO accessors >> sunxi: H6: use writel_relaxed for DRAM timing register accesses > > These have build issues with arm32, please send another series. Thanks for the elaborate error report ;-) There is commit 6478848d165b63293f7021db9b70ce25a1e1062c, which does basically the same thing as patch 2/3 in this series and was merged by Tom already. This causes the double definition. So just dropping the middle patch from this series should do the trick. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
On 4/30/19 2:42 PM, Marek Vasut wrote: On 4/30/19 10:38 PM, Atish Patra wrote: On 4/30/19 12:11 PM, Marek Vasut wrote: On 4/30/19 8:13 PM, Atish Patra wrote: On 4/30/19 2:52 AM, Marek Vasut wrote: On 4/30/19 3:27 AM, Atish Patra wrote: [...] Yes. FIT image parsing can be done in that way. However, the idea was here to load Image.gz directly. Image.gz is default compressed Linux kernel image format in RISC-V. Sigh, and the image header is compressed as well, so there's no way to identify the image format, right ? And there's no decompressor, so the dcompressing has to be done by bootloader, which would need some sort of very smart way of figuring out which exact compression method is used ? Yes. Image.gz is always gunzip. So checking first two bytes is enough to confirm that it is a gz file. What happens once people start feeding it more exotic compression methods, like LZ4 or LZO or LZMA for example ? booti command help will clearly state that it can only boot kernel from Image or Image.gz. static char booti_help_text[] = "[addr [initrd[:size]] [fdt]]\n" - " - boot arm64 Linux Image stored in memory\n" + " - boot arm64 Linux Image or riscv Linux Image/Image.gz stored in memory\n" Obvious question -- does this Image.gz stuff apply to arm64 ? arm64 builds Image.gz but booti for arm64 doesn't use it. I guess Image.gz can be used in FIT image for ARM64 but I am not sure which platform actually uses it. This patch only enables support for RISC-V. Can't this be made generic ? I think so if I just move the gzip detection and decompression code to cmd/booti.c. I will update the v3 patch with this. Regards, Atish [...] ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
On 4/30/19 10:38 PM, Atish Patra wrote: > On 4/30/19 12:11 PM, Marek Vasut wrote: >> On 4/30/19 8:13 PM, Atish Patra wrote: >>> On 4/30/19 2:52 AM, Marek Vasut wrote: On 4/30/19 3:27 AM, Atish Patra wrote: [...] >>> Yes. FIT image parsing can be done in that way. However, the idea >>> was >>> here to load Image.gz directly. Image.gz is default compressed Linux >>> kernel image format in RISC-V. >> >> Sigh, and the image header is compressed as well, so there's no >> way to >> identify the image format, right ? And there's no decompressor, so >> the >> dcompressing has to be done by bootloader, which would need some >> sort of >> very smart way of figuring out which exact compression method is >> used ? >> > Yes. Image.gz is always gunzip. So checking first two bytes is > enough to > confirm that it is a gz file. What happens once people start feeding it more exotic compression methods, like LZ4 or LZO or LZMA for example ? >>> >>> booti command help will clearly state that it can only boot kernel from >>> Image or Image.gz. >>> >>> static char booti_help_text[] = >>> "[addr [initrd[:size]] [fdt]]\n" >>> - " - boot arm64 Linux Image stored in memory\n" >>> + " - boot arm64 Linux Image or riscv Linux Image/Image.gz stored >>> in memory\n" >> >> Obvious question -- does this Image.gz stuff apply to arm64 ? >> > > arm64 builds Image.gz but booti for arm64 doesn't use it. I guess > Image.gz can be used in FIT image for ARM64 but I am not sure which > platform actually uses it. > > This patch only enables support for RISC-V. Can't this be made generic ? [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cyclone5 reboot: warm or cold reset?
On Tue, 2019-04-30 at 22:09 +0200, Marek Vasut wrote: > On 4/30/19 10:05 PM, Simon Goldschmidt wrote: > > Am 30.04.2019 um 22:01 schrieb Marek Vasut: > > > On 4/30/19 9:19 PM, Simon Goldschmidt wrote: > > > > Am 30.04.2019 um 21:08 schrieb Marek Vasut: > > > > > On 4/30/19 8:56 PM, Simon Goldschmidt wrote: > > > > > > Hi all, > > > > > > > > > > Hi, > > > > > > > > > > > I added some of those I think worth discussing this. > > > > > > > > > > > > I was chasing a reboot problem on one of our cyclone5 boards today. > > > > > > That > > > > > > board boots from a "n25q256a" qspi flash. Up to now, U-Boot > > > > > > configures > > > > > > the boot ROM to just jump to OCRAM when rebooting and hope that the > > > > > > SPL > > > > > > is still there and fully working (nothing's overwritten). > > > > > > > > > > > > For a long running production board, this is of course crap, as a > > > > > > pointer running wild could always overwrite the SRAM. But there was > > > > > > not > > > > > > much we could do about it as long as U-Boot and/or Linux were > > > > > > putting > > > > > > out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot > > > > > > ROM > > > > > > unless in 3-byte mode. And while Linux "reboot" could reset the chip > > > > > > into 3-byte mode, "reboot -f" and U-Boot "reset" can't. > > > > > > > > > > > > Now with U-Boot and Linux having everything in place to leave the > > > > > > spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte > > > > > > opcodes, I thought rebooting from Linux would now work with loading > > > > > > the > > > > > > SPL from qspi (by disabling the magic that tells the Boot ROM to > > > > > > jump to > > > > > > OCRAM). > > > > > > > > > > Well, if the chip is in the middle of some operation (erase or page > > > > > program) and you reset the CPU just at the right moment, leaving the > > > > > chip in 3byte addressing mode won't help you anyway. > > > > > > > > Right, but unfortunately, that's not an issue for us :-) > > > > > > > > > The only reliable solution is to connect reset to the SPI NOR chip and > > > > > trigger the reset. Of course, some SPI NORs have a reset line, but > > > > > it is > > > > > not connected internally, which is a fantastic design. I think the > > > > > N25Q256 had exactly such a problem, but only on some revisions, to > > > > > make > > > > > it even more messed up. > > > > > > > > Yeah, well, let's just assume there *are* boards that either use spi-nor > > > > chips without a working reset line and there *are* boards with spi-nor > > > > chips having a reset line that is just not connected... > > > > > > > > > > However, I found the Boot ROM still cannot load the SPL because it > > > > > > tries > > > > > > to load at 100 MHz (while on cold boot, it loads with 6.25 MHz). > > > > > > > > > > Look at > > > > > https://patchwork.ozlabs.org/patch/729738/ > > > > > > > > > > > > > Interesting, I didn't know that one. I doesn't seem to have made it into > > > > the tree, but it's a different thing slightly: it prevents the Boot ROM > > > > jumping to OCRAM, but that's what I did and it still fails as the Boot > > > > ROM uses a constant divider "4" resulting in loading SPL with 100 MHz > > > > from the qspi chip. And that somehow fails. > > > > > > It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to > > > a code which resets the PLLs and then triggers another warm reset, this > > > time with a jump address pointing to the SPL. > > > > Well, what I read from hat patch is that it only writes the magic to > > make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL > > from QSPI for csel == 0 in my case (and I do have csel ==0 0). > > > > I fail to see the "somewhere else" in the link you sent. Maybe that was > > in an older version? > > That's quite possible , there were a few iterations. In some ES silicon for C5, which happens to be what is used on the DE0 board, there was an issue that required CSEL=0. As noted in the comments, for CSEL=0 the bootrom does not reset the PLL/clock configurations and as a result the QSPI clock in your case is not being modified to a useable clock for the bootrom. The patch just forced a cold reset when csel=0. personally, i would like a default to cold resets, with an option to use warm resets should a use case exist (such as preserving DDR contents). What changed with 4-byte access in the QSPI? --dalon > > > > > If I change the handoff files so that the qspi core runs at 200 MHz > > > > instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold > > > > reset would still be better... > > > > > > > > > > However, when triggering cold reset instead of warm reset in rstmgr > > > > > > ctrl > > > > > > register [1], it works fine (and qspi clock is 6.25 MHz). > > > > > > > > > > > > Now the question is: why do we trigger warm reset instead of cold > > > > > > reset? > > > > > > > > > > I'd like to know that too. But it's
Re: [U-Boot] Pull request: u-boot-net.git master
On Tue, Apr 30, 2019 at 09:15:33PM +, Joe Hershberger wrote: > On Tue, Mar 19, 2019 at 5:41 PM Tom Rini wrote: > > > > On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote: > > > > > Hi Tom, > > > > > > These patches passed the CI build here: > > > https://travis-ci.org/jhershbe/u-boot/builds/501807294 > > > > > > The following changes since commit > > > 2e8092d94f40a5692baf3ec768ce3216a7bf032a: > > > > > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 > > > 15:48:57 -0400) > > > > > > are available in the git repository at: > > > > > > > > > git://git.denx.de/u-boot-net.git master > > > > > > for you to fetch changes up to 85f05f72bacc2d047731fc64801e4f6b34cf: > > > > > > net: phy: aquantia: Set only autoneg on in register 4.c441 (2019-03-12 > > > 13:13:37 -0500) > > > > > > > NAK. One of: > > The first bad commit could be any of: > > 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1 > > 8860e1563f38d16f7ae29053018cd445c0fa111d > > ebb5027d69196dd83fd0fa5bd91fca07acfd77be > > 09e0a36497c84273e5b22488d5af01bf0ba17469 > > 841b9df209e37fe1bfefa5f44e837a0ad497443f > > 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447 > > 7aadf5134f2f5771689d0657b69875d0a464859d > > d35488518f3c16d305092c816a5129f45a0b62d7 > > Breaks am335x_evm ethernet: > > 18:39:52 => => dhcp > > 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to > > complete... done > > 18:39:52 link up on port 0, speed 1000, full duplex > > 18:39:52 BOOTP broadcast 1 > > 18:39:52 BOOTP broadcast 2 > > 18:39:52 BOOTP broadcast 3 > > 18:39:52 BOOTP broadcast 4 > > 18:39:52 BOOTP broadcast 5 > > 18:39:52 BOOTP broadcast 6 > > 18:39:52 BOOTP broadcast 7 > > 18:39:52 BOOTP broadcast 8 > > 18:39:52 BOOTP broadcast 9 > > 18:39:52 BOOTP broadcast 10 > > 18:39:52 BOOTP broadcast 11 > > 18:39:52 BOOTP broadcast 12 > > 18:39:52 BOOTP broadcast 13 > > 18:39:52 BOOTP broadcast 14 > > 18:39:52 BOOTP broadcast 15 > > 18:39:52 BOOTP broadcast 16 > > 18:39:52 BOOTP broadcast 17 > > I rebased the series on the current master and I can't reproduce this > dhcp issue. On the original series I saw broken DHCP only with "net: > phy: micrel: Use correct skew values on KSZ9021" which doesn't make > any sense because that phy is not used on BBB and isn't even compiled > in. Also, the issue doesn't reproduce when the next patch is applied. > Even that oddity doesn't happen after the rebase. > > Also the SPL for boneblack is too big to build with some of the > patches in this series now, so I'm not sure how that should be > handled. Drop those parts for now I guess and we'll have to look harder at them stand-alone? And I assume you mean am335x_boneblack_vboot is too large? Or am335x_evm itself? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] common: bouncebuf: handle address in sram for rockchip platform
Hi Kever, On 4/2/19 10:46 AM, Kever Yang wrote: > Rockchip SOC's mmc controller does not support read data > from mmc to sram, we need a bounce buffer(in sdram), and then > copy to sram. what exactly is the limitation here? I mean a DMA engine does not care where it is copying to. Additionally I was observing recently, that copying from SD card to SRAM works on RK3399 boards with 4 GB of RAM. I see a data error in dwmci_data_transfer() only on 2 GB boards. Therefore my question: Is this maybe just a problem of the memory area not being mapped in SPL? Thanks, Christoph > > Signed-off-by: Kever Yang > --- > > common/bouncebuf.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/common/bouncebuf.c b/common/bouncebuf.c > index a7098e2caf..364fb17c96 100644 > --- a/common/bouncebuf.c > +++ b/common/bouncebuf.c > @@ -26,6 +26,18 @@ static int addr_aligned(struct bounce_buffer *state) > return 0; > } > > +#ifdef CONFIG_ARCH_ROCKCHIP > + /* > + * Rockchip SOC's mmc controller does not support read data > + * from mmc to sram, we need a bounce buffer(in sdram), and then > + * copy to sram. > + */ > + if (((ulong)state->user_buffer & 0xfff8) == > + CONFIG_ROCKCHIP_IRAM_BASE) { > + debug("Unsupport IRAM space %p\n", state->user_buffer); > + return 0; > + } > +#endif > /* Aligned */ > return 1; > } > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Tue, Mar 19, 2019 at 5:41 PM Tom Rini wrote: > > On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote: > > > Hi Tom, > > > > These patches passed the CI build here: > > https://travis-ci.org/jhershbe/u-boot/builds/501807294 > > > > The following changes since commit 2e8092d94f40a5692baf3ec768ce3216a7bf032a: > > > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 > > 15:48:57 -0400) > > > > are available in the git repository at: > > > > > > git://git.denx.de/u-boot-net.git master > > > > for you to fetch changes up to 85f05f72bacc2d047731fc64801e4f6b34cf: > > > > net: phy: aquantia: Set only autoneg on in register 4.c441 (2019-03-12 > > 13:13:37 -0500) > > > > NAK. One of: > The first bad commit could be any of: > 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1 > 8860e1563f38d16f7ae29053018cd445c0fa111d > ebb5027d69196dd83fd0fa5bd91fca07acfd77be > 09e0a36497c84273e5b22488d5af01bf0ba17469 > 841b9df209e37fe1bfefa5f44e837a0ad497443f > 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447 > 7aadf5134f2f5771689d0657b69875d0a464859d > d35488518f3c16d305092c816a5129f45a0b62d7 > Breaks am335x_evm ethernet: > 18:39:52 => => dhcp > 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to > complete... done > 18:39:52 link up on port 0, speed 1000, full duplex > 18:39:52 BOOTP broadcast 1 > 18:39:52 BOOTP broadcast 2 > 18:39:52 BOOTP broadcast 3 > 18:39:52 BOOTP broadcast 4 > 18:39:52 BOOTP broadcast 5 > 18:39:52 BOOTP broadcast 6 > 18:39:52 BOOTP broadcast 7 > 18:39:52 BOOTP broadcast 8 > 18:39:52 BOOTP broadcast 9 > 18:39:52 BOOTP broadcast 10 > 18:39:52 BOOTP broadcast 11 > 18:39:52 BOOTP broadcast 12 > 18:39:52 BOOTP broadcast 13 > 18:39:52 BOOTP broadcast 14 > 18:39:52 BOOTP broadcast 15 > 18:39:52 BOOTP broadcast 16 > 18:39:52 BOOTP broadcast 17 I rebased the series on the current master and I can't reproduce this dhcp issue. On the original series I saw broken DHCP only with "net: phy: micrel: Use correct skew values on KSZ9021" which doesn't make any sense because that phy is not used on BBB and isn't even compiled in. Also, the issue doesn't reproduce when the next patch is applied. Even that oddity doesn't happen after the rebase. Also the SPL for boneblack is too big to build with some of the patches in this series now, so I'm not sure how that should be handled. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/5] riscv: configs: AE350 will use CONFIG_OF_SEPARATE when boots from flash
Hi Rick, On Tue, 2019-04-30 at 13:49 +0800, Andes wrote: > From: Rick Chen > > When AE350 boots from flash, use CONFIG_OF_SEPARATE instead of > CONFIG_OF_BOARD. > > Also remove unused code about prior_stage_fdt_address. > And modify CONFIG_SYS_FDT_BASE as flash address. > > Signed-off-by: Rick Chen > Cc: Greentime Hu > --- > board/AndesTech/ax25-ae350/ax25-ae350.c | 4 > configs/ae350_rv32_xip_defconfig| 2 +- > configs/ae350_rv64_xip_defconfig| 2 +- > include/configs/ax25-ae350.h| 2 +- > 4 files changed, 3 insertions(+), 7 deletions(-) > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c > b/board/AndesTech/ax25-ae350/ax25-ae350.c > index d343453..3d65ce7 100644 > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c > @@ -67,10 +67,6 @@ ulong board_flash_get_legacy(ulong base, int banknum, > flash_info_t *info) > > void *board_fdt_blob_setup(void) > { > - void **ptr = (void *)_stage_fdt_address; > - if (fdt_magic(*ptr) == FDT_MAGIC) > - return (void *)*ptr; > - > return (void *)CONFIG_SYS_FDT_BASE; > } > > diff --git a/configs/ae350_rv32_xip_defconfig > b/configs/ae350_rv32_xip_defconfig > index 76534f2..07f1ecc 100644 > --- a/configs/ae350_rv32_xip_defconfig > +++ b/configs/ae350_rv32_xip_defconfig > @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y > # CONFIG_CMD_SETEXPR is not set > CONFIG_BOOTP_PREFER_SERVERIP=y > CONFIG_CMD_CACHE=y > -CONFIG_OF_BOARD=y > +CONFIG_OF_SEPARATE=y > CONFIG_DEFAULT_DEVICE_TREE="ae350_32" > CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_NET_RANDOM_ETHADDR=y > diff --git a/configs/ae350_rv64_xip_defconfig > b/configs/ae350_rv64_xip_defconfig > index f7f2925..28afd81 100644 > --- a/configs/ae350_rv64_xip_defconfig > +++ b/configs/ae350_rv64_xip_defconfig > @@ -16,7 +16,7 @@ CONFIG_CMD_SF_TEST=y > # CONFIG_CMD_SETEXPR is not set > CONFIG_BOOTP_PREFER_SERVERIP=y > CONFIG_CMD_CACHE=y > -CONFIG_OF_BOARD=y > +CONFIG_OF_SEPARATE=y > CONFIG_DEFAULT_DEVICE_TREE="ae350_64" > CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_NET_RANDOM_ETHADDR=y > diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h > index 395f3a4..a4037f3 100644 > --- a/include/configs/ax25-ae350.h > +++ b/include/configs/ax25-ae350.h > @@ -40,7 +40,7 @@ > #define CONFIG_SYS_MALLOC_LEN (512 << 10) > > /* DT blob (fdt) address */ > -#define CONFIG_SYS_FDT_BASE 0x000f > +#define CONFIG_SYS_FDT_BASE 0x800f > > /* > * Physical Memory Map As a note, with CONFIG_OF_SEPARATE, the device tree will be automatically appended to the U-Boot binary. A fixed location for the device tree therefore does not have to be defined, meaning that you could remove the CONFIG_SYS_FDT_BASE define and the board_fdt_blob_setup() function. There are also reasons for using a fixed location for the device tree, so this is also fine. :) Reviewed-by: Lukas Auer Thanks, Lukas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/5] riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is enabled
On Tue, 2019-04-30 at 13:49 +0800, Andes wrote: > From: Rick Chen > > This patch will fix prior_stage_fdt_address write failure problem, when > AE350 boots from flash. > > When AE350 boots from flash, prior_stage_fdt_address will be flash > address, we shall avoid it to be written. > > Signed-off-by: Rick Chen > Cc: Greentime Hu > --- > arch/riscv/cpu/cpu.c | 2 ++ > arch/riscv/cpu/start.S | 2 ++ > 2 files changed, 4 insertions(+) > Reviewed-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] spi: Kconfig: Mark LPC32XX_SSP has BROKEN
Hi Jagan, On 04/28/2019 11:48 PM, Jagan Teki wrote: > Mark LPC32XX_SSP has BROKEN, this so the resulting build shows > warning for broken configuration enabled and associated code > will remove in v2019.07 release. > > Cc: Vladimir Zapolskiy > Cc: Albert ARIBAUD > Signed-off-by: Jagan Teki > --- > drivers/spi/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 55f0d6cf2b..5fbe17bb20 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -369,6 +369,7 @@ config KIRKWOOD_SPI > > config LPC32XX_SSP > bool "LPC32XX SPI Driver" > + select BROKEN > help > Enable support for SPI on LPC32xx > > Acked-by: Vladimir Zapolskiy Thank you for the change, as we've discussed earlier I won't have objections against the driver removal when time is up. Thus you can locally prepare a removal change in advance, the one which you've sent earlier needs a minor update, please also remove lpc32xx_ssp_init() function and its usage in the board files. -- Best wishes, Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
On 4/30/19 12:11 PM, Marek Vasut wrote: On 4/30/19 8:13 PM, Atish Patra wrote: On 4/30/19 2:52 AM, Marek Vasut wrote: On 4/30/19 3:27 AM, Atish Patra wrote: [...] Yes. FIT image parsing can be done in that way. However, the idea was here to load Image.gz directly. Image.gz is default compressed Linux kernel image format in RISC-V. Sigh, and the image header is compressed as well, so there's no way to identify the image format, right ? And there's no decompressor, so the dcompressing has to be done by bootloader, which would need some sort of very smart way of figuring out which exact compression method is used ? Yes. Image.gz is always gunzip. So checking first two bytes is enough to confirm that it is a gz file. What happens once people start feeding it more exotic compression methods, like LZ4 or LZO or LZMA for example ? booti command help will clearly state that it can only boot kernel from Image or Image.gz. static char booti_help_text[] = "[addr [initrd[:size]] [fdt]]\n" - " - boot arm64 Linux Image stored in memory\n" + " - boot arm64 Linux Image or riscv Linux Image/Image.gz stored in memory\n" Obvious question -- does this Image.gz stuff apply to arm64 ? arm64 builds Image.gz but booti for arm64 doesn't use it. I guess Image.gz can be used in FIT image for ARM64 but I am not sure which platform actually uses it. This patch only enables support for RISC-V. (I will update the help text with Image.gz part) Anything other than that, it will fail with following error. "Bad Linux RISCV Image magic!" Right, so we're implementing file(1)-lite here to detect the format. The tricky part is length of the compressed file. I took another look at the gunzip implementation in U-Boot. It looks like to me that compressed header length just to parse the header correctly. It doesn't actually use the "length" to decompress. In fact, it updates the length with uncompressed bytes after the decompression. That's possible. David suggested a better idea. 1. User can supply kernel_size and we can store in environment variable. 2. If the size is empty or greater than CONFIG_SYS_BOOTM_LEN, booti fails with appropriate error message. You can keep decompressing until you reach $bootm_len, sure . Decompression happens for actual uncompressed length which is encoded into the compressed file footer. So we don't have to worry about how much we decompress. But a correct file_size helps to avoid decompressing a possible corrupt compressed file. I will update the patch as per David's suggestion. Regards, Atish We will update the documents to add the additional step for Image.gz I am fine with either approach. Any preference ? Regards, Atish ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [BUG] test_avb_persistent_values() fails
Hello Igor, when I run `make tests` with current origin/master commit a69120a0d7c8d4044cdaceea9eb03913ba4e49c7 I get an error. I think your submitted this test recently: commit fc1fe01b08ce ("avb: add support for named persistent values") u_boot_console = @pytest.mark.buildconfigspec('cmd_avb') @pytest.mark.buildconfigspec('optee_ta_avb') def test_avb_persistent_values(u_boot_console): """Test reading/writing persistent storage to avb """ response = u_boot_console.run_command('avb init %s' % str(mmc_dev)) assert response == '' response = u_boot_console.run_command('avb write_pvalue test value_value') assert response == 'Wrote 12 bytes' response = u_boot_console.run_command('avb read_pvalue test 12') > assert response == 'Read 12 bytes, value = value_value' E AssertionError: assert 'Read 12 byte...alue_value/XU' == 'Read 12 bytes...= value_value' E - Read 12 bytes, value = value_value/XU E ? --- E + Read 12 bytes, value = value_value test/py/tests/test_avb.py:134: AssertionError Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
Hi, On 4/19/19 6:38 AM, Alex Kiernan wrote: > This converts the following to Kconfig: >CONFIG_SUPPORT_EMMC_BOOT > > Signed-off-by: Alex Kiernan > --- > Green travis build: > > https://travis-ci.org/akiernan/u-boot/builds/521906850 > > Testing affected boards for configuration changes: > > boards.cfg is up to date. Nothing to do. > Summary of 3 commits for 95 boards (4 threads, 1 job per thread) > 01: Merge tag 'u-boot-imx-20190415' of git://git.denx.de/u-boot-imx > aarch64: w+ xilinx_zynqmp_mini_emmc1 xilinx_zynqmp_mini_emmc0 > xilinx_zynqmp_mini_qspi clearfog_gt_8k imx8qxp_mek xilinx_zynqmp_mini > xilinx_zynqmp_mini_nand imx8mq_evk > arm: w+ cm_t54 cl-som-imx7 marsboard clearfog apalis_imx6 warp7 > pico-hobbit-imx7d pico-pi-imx6ul dms-ba16 arndale riotboard > pico-hobbit-imx6ul colibri_imx7 pico-imx7d xpress_spl opos6uldev warp7_bl33 > imx6dl_mamoj ge_bx50v3 display5 mx7dsabresd_qspi display5_factory > colibri_imx7_emmc gwventana_nand mx7dsabresd gwventana_gw5904 gwventana_emmc > am57xx_hs_evm_usb omap5_uevm brppt1_spi xilinx_zynqmp_r5 vinco mx6sabresd > warp riotboard_spl vining_2000 zc5601 zc5202 xpress pico-imx6ul dms-ba16-1g > pico-pi-imx7d > 02: configs: Resync with savedefconfig > 03: Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig > > configs/opos6uldev_defconfig | 1 + > include/configs/opos6uldev.h | 3 --- Tested-by: Sébastien Szymanski Regards, -- Sébastien Szymanski Software engineer, Armadeus Systems Tel: +33 (0)9 72 29 41 44 Fax: +33 (0)9 72 28 79 26 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cyclone5 reboot: warm or cold reset?
On 4/30/19 10:05 PM, Simon Goldschmidt wrote: > Am 30.04.2019 um 22:01 schrieb Marek Vasut: >> On 4/30/19 9:19 PM, Simon Goldschmidt wrote: >>> Am 30.04.2019 um 21:08 schrieb Marek Vasut: On 4/30/19 8:56 PM, Simon Goldschmidt wrote: > Hi all, Hi, > I added some of those I think worth discussing this. > > I was chasing a reboot problem on one of our cyclone5 boards today. > That > board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures > the boot ROM to just jump to OCRAM when rebooting and hope that the > SPL > is still there and fully working (nothing's overwritten). > > For a long running production board, this is of course crap, as a > pointer running wild could always overwrite the SRAM. But there was > not > much we could do about it as long as U-Boot and/or Linux were putting > out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot > ROM > unless in 3-byte mode. And while Linux "reboot" could reset the chip > into 3-byte mode, "reboot -f" and U-Boot "reset" can't. > > Now with U-Boot and Linux having everything in place to leave the > spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte > opcodes, I thought rebooting from Linux would now work with loading > the > SPL from qspi (by disabling the magic that tells the Boot ROM to > jump to > OCRAM). Well, if the chip is in the middle of some operation (erase or page program) and you reset the CPU just at the right moment, leaving the chip in 3byte addressing mode won't help you anyway. >>> >>> Right, but unfortunately, that's not an issue for us :-) >>> The only reliable solution is to connect reset to the SPI NOR chip and trigger the reset. Of course, some SPI NORs have a reset line, but it is not connected internally, which is a fantastic design. I think the N25Q256 had exactly such a problem, but only on some revisions, to make it even more messed up. >>> >>> Yeah, well, let's just assume there *are* boards that either use spi-nor >>> chips without a working reset line and there *are* boards with spi-nor >>> chips having a reset line that is just not connected... >>> > However, I found the Boot ROM still cannot load the SPL because it > tries > to load at 100 MHz (while on cold boot, it loads with 6.25 MHz). Look at https://patchwork.ozlabs.org/patch/729738/ >>> >>> Interesting, I didn't know that one. I doesn't seem to have made it into >>> the tree, but it's a different thing slightly: it prevents the Boot ROM >>> jumping to OCRAM, but that's what I did and it still fails as the Boot >>> ROM uses a constant divider "4" resulting in loading SPL with 100 MHz >>> from the qspi chip. And that somehow fails. >> >> It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to >> a code which resets the PLLs and then triggers another warm reset, this >> time with a jump address pointing to the SPL. > > Well, what I read from hat patch is that it only writes the magic to > make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL > from QSPI for csel == 0 in my case (and I do have csel ==0 0). > > I fail to see the "somewhere else" in the link you sent. Maybe that was > in an older version? That's quite possible , there were a few iterations. >>> If I change the handoff files so that the qspi core runs at 200 MHz >>> instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold >>> reset would still be better... >>> > However, when triggering cold reset instead of warm reset in rstmgr > ctrl > register [1], it works fine (and qspi clock is 6.25 MHz). > > Now the question is: why do we trigger warm reset instead of cold > reset? I'd like to know that too. But it's likely because of various AMP setups, where the second CPU or the FPGA do something and you don't want to interrupt that operation by the primary CPU's reset. I haven't seen such deployments much myself though. >>> >>> Ok, from reading the above thread, I guess there might be use cases for >>> the warm reset but not for us. So I can make Linux using cold reset via >>> a Kernel command line parameter but I can't do it for U-Boot. >>> >>> Looks like we need a method to control this for U-Boot. Unless someone >>> comes up with a better explanation, that is. >> >> Update the "reset" command to take a parameter -- type of reset. >> It's been on my list of things to do for a while, but didn't get around >> to it. > > Right, something like that. Probably the same enum Linux uses (enum > reboot_mode), to make things clearer. Right > Regards, > Simon > >> >>> Regards, >>> Simon >>> > Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux > also uses warm reset by default, but I'm tempted to send a patch for > both U-Boot and Linux
Re: [U-Boot] cyclone5 reboot: warm or cold reset?
Am 30.04.2019 um 22:01 schrieb Marek Vasut: On 4/30/19 9:19 PM, Simon Goldschmidt wrote: Am 30.04.2019 um 21:08 schrieb Marek Vasut: On 4/30/19 8:56 PM, Simon Goldschmidt wrote: Hi all, Hi, I added some of those I think worth discussing this. I was chasing a reboot problem on one of our cyclone5 boards today. That board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures the boot ROM to just jump to OCRAM when rebooting and hope that the SPL is still there and fully working (nothing's overwritten). For a long running production board, this is of course crap, as a pointer running wild could always overwrite the SRAM. But there was not much we could do about it as long as U-Boot and/or Linux were putting out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM unless in 3-byte mode. And while Linux "reboot" could reset the chip into 3-byte mode, "reboot -f" and U-Boot "reset" can't. Now with U-Boot and Linux having everything in place to leave the spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte opcodes, I thought rebooting from Linux would now work with loading the SPL from qspi (by disabling the magic that tells the Boot ROM to jump to OCRAM). Well, if the chip is in the middle of some operation (erase or page program) and you reset the CPU just at the right moment, leaving the chip in 3byte addressing mode won't help you anyway. Right, but unfortunately, that's not an issue for us :-) The only reliable solution is to connect reset to the SPI NOR chip and trigger the reset. Of course, some SPI NORs have a reset line, but it is not connected internally, which is a fantastic design. I think the N25Q256 had exactly such a problem, but only on some revisions, to make it even more messed up. Yeah, well, let's just assume there *are* boards that either use spi-nor chips without a working reset line and there *are* boards with spi-nor chips having a reset line that is just not connected... However, I found the Boot ROM still cannot load the SPL because it tries to load at 100 MHz (while on cold boot, it loads with 6.25 MHz). Look at https://patchwork.ozlabs.org/patch/729738/ Interesting, I didn't know that one. I doesn't seem to have made it into the tree, but it's a different thing slightly: it prevents the Boot ROM jumping to OCRAM, but that's what I did and it still fails as the Boot ROM uses a constant divider "4" resulting in loading SPL with 100 MHz from the qspi chip. And that somehow fails. It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to a code which resets the PLLs and then triggers another warm reset, this time with a jump address pointing to the SPL. Well, what I read from hat patch is that it only writes the magic to make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL from QSPI for csel == 0 in my case (and I do have csel ==0 0). I fail to see the "somewhere else" in the link you sent. Maybe that was in an older version? If I change the handoff files so that the qspi core runs at 200 MHz instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold reset would still be better... However, when triggering cold reset instead of warm reset in rstmgr ctrl register [1], it works fine (and qspi clock is 6.25 MHz). Now the question is: why do we trigger warm reset instead of cold reset? I'd like to know that too. But it's likely because of various AMP setups, where the second CPU or the FPGA do something and you don't want to interrupt that operation by the primary CPU's reset. I haven't seen such deployments much myself though. Ok, from reading the above thread, I guess there might be use cases for the warm reset but not for us. So I can make Linux using cold reset via a Kernel command line parameter but I can't do it for U-Boot. Looks like we need a method to control this for U-Boot. Unless someone comes up with a better explanation, that is. Update the "reset" command to take a parameter -- type of reset. It's been on my list of things to do for a while, but didn't get around to it. Right, something like that. Probably the same enum Linux uses (enum reboot_mode), to make things clearer. Regards, Simon Regards, Simon Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux also uses warm reset by default, but I'm tempted to send a patch for both U-Boot and Linux to use cold reset by default. Any insight on the consequences of using cold reset instead of warm reset would be really appreciated! Regards, Simon [1] https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cyclone5 reboot: warm or cold reset?
On 4/30/19 9:19 PM, Simon Goldschmidt wrote: > Am 30.04.2019 um 21:08 schrieb Marek Vasut: >> On 4/30/19 8:56 PM, Simon Goldschmidt wrote: >>> Hi all, >> >> Hi, >> >>> I added some of those I think worth discussing this. >>> >>> I was chasing a reboot problem on one of our cyclone5 boards today. That >>> board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures >>> the boot ROM to just jump to OCRAM when rebooting and hope that the SPL >>> is still there and fully working (nothing's overwritten). >>> >>> For a long running production board, this is of course crap, as a >>> pointer running wild could always overwrite the SRAM. But there was not >>> much we could do about it as long as U-Boot and/or Linux were putting >>> out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM >>> unless in 3-byte mode. And while Linux "reboot" could reset the chip >>> into 3-byte mode, "reboot -f" and U-Boot "reset" can't. >>> >>> Now with U-Boot and Linux having everything in place to leave the >>> spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte >>> opcodes, I thought rebooting from Linux would now work with loading the >>> SPL from qspi (by disabling the magic that tells the Boot ROM to jump to >>> OCRAM). >> >> Well, if the chip is in the middle of some operation (erase or page >> program) and you reset the CPU just at the right moment, leaving the >> chip in 3byte addressing mode won't help you anyway. > > Right, but unfortunately, that's not an issue for us :-) > >> >> The only reliable solution is to connect reset to the SPI NOR chip and >> trigger the reset. Of course, some SPI NORs have a reset line, but it is >> not connected internally, which is a fantastic design. I think the >> N25Q256 had exactly such a problem, but only on some revisions, to make >> it even more messed up. > > Yeah, well, let's just assume there *are* boards that either use spi-nor > chips without a working reset line and there *are* boards with spi-nor > chips having a reset line that is just not connected... > >> >>> However, I found the Boot ROM still cannot load the SPL because it tries >>> to load at 100 MHz (while on cold boot, it loads with 6.25 MHz). >> >> Look at https://patchwork.ozlabs.org/patch/729738/ > > Interesting, I didn't know that one. I doesn't seem to have made it into > the tree, but it's a different thing slightly: it prevents the Boot ROM > jumping to OCRAM, but that's what I did and it still fails as the Boot > ROM uses a constant divider "4" resulting in loading SPL with 100 MHz > from the qspi chip. And that somehow fails. It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to a code which resets the PLLs and then triggers another warm reset, this time with a jump address pointing to the SPL. > If I change the handoff files so that the qspi core runs at 200 MHz > instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold > reset would still be better... > >> >>> However, when triggering cold reset instead of warm reset in rstmgr ctrl >>> register [1], it works fine (and qspi clock is 6.25 MHz). >>> >>> Now the question is: why do we trigger warm reset instead of cold reset? >> >> I'd like to know that too. But it's likely because of various AMP >> setups, where the second CPU or the FPGA do something and you don't want >> to interrupt that operation by the primary CPU's reset. I haven't seen >> such deployments much myself though. > > Ok, from reading the above thread, I guess there might be use cases for > the warm reset but not for us. So I can make Linux using cold reset via > a Kernel command line parameter but I can't do it for U-Boot. > > Looks like we need a method to control this for U-Boot. Unless someone > comes up with a better explanation, that is. Update the "reset" command to take a parameter -- type of reset. It's been on my list of things to do for a while, but didn't get around to it. > Regards, > Simon > >> >>> Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux >>> also uses warm reset by default, but I'm tempted to send a patch for >>> both U-Boot and Linux to use cold reset by default. >>> >>> Any insight on the consequences of using cold reset instead of warm >>> reset would be really appreciated! >>> >>> Regards, >>> Simon >>> >>> [1] >>> https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html >>> >>> >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot >> >> > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting MX6 via Serial Download after DM conversion
On Tue, Apr 30, 2019 at 02:39:17PM -0300, Fabio Estevam wrote: > Hi Tom, > > On Mon, Apr 29, 2019 at 2:57 PM Tom Rini wrote: > > > imx_usb is doing some checking of the second binary it sends along? > > That sounds odd to start with, is there some specific history there? > > My understanding is that imx_usb_loader expects to find a valid IVT entry. > > After the conversion to DM, a FIT image is used on > mx6sabresd_defconfig and such IVT can no longer be found, causing > imx_usb_loader to fail to loading u-boot-dtb.img. > > It would be nice if we can come up with a solution, as loosing the > ability to load via imx_usb_loader has a negative impact for users. Right, what I'm getting at is, why does imx_usb_loader need to find a specific anything in the binary? What is that IVT used for exactly? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] usb: ohci: ohci-da8xx: Enable da850-ohci driver with DM support
On 4/30/19 12:21 PM, Adam Ford wrote: [..] > +#if CONFIG_IS_ENABLED(DM_USB) > +static int ohci_da8xx_probe(struct udevice *dev) > +{ > + struct ohci_regs *regs = (struct ohci_regs *)devfdt_get_addr(dev); > + struct da8xx_ohci *priv = dev_get_priv(dev); > + int i, err, ret, clock_nb; > + > + err = 0; > + priv->clock_count = 0; > + clock_nb = dev_count_phandle_with_args(dev, "clocks", "#clock-cells"); > + if (clock_nb > 0) { What happens if clock_nb == -ENOENT ? I think what you want here is if (clock_nb < 0) { ... return clock_nb; } if (clock_nb > 0) { ... } > + priv->clocks = devm_kcalloc(dev, clock_nb, sizeof(struct clk), > + GFP_KERNEL); > + if (!priv->clocks) > + return -ENOMEM; > + > + for (i = 0; i < clock_nb; i++) { > + err = clk_get_by_index(dev, i, >clocks[i]); > + if (err < 0) > + break; > + > + err = clk_enable(>clocks[i]); > + if (err) { > + dev_err(dev, "failed to enable clock %d\n", i); > + clk_free(>clocks[i]); > + goto clk_err; > + } > + priv->clock_count++; > + } > + } else if (clock_nb != -ENOENT) { > + dev_err(dev, "failed to get clock phandle(%d)\n", clock_nb); > + return clock_nb; > + } > + > + err = usb_cpu_init(); > + > + if (err) > + goto clk_err; > + > + err = ohci_register(dev, regs); > + if (err) > + goto phy_err; > + > + return 0; > + > +phy_err: > + ret = usb_cpu_stop(); > + if (ret) > + dev_err(dev, "failed to shutdown usb phy\n"); > + > +clk_err: > + ret = clk_release_all(priv->clocks, priv->clock_count); > + if (ret) > + dev_err(dev, "failed to disable all clocks\n"); > + > + return err; > +} > + > +static int ohci_da8xx_remove(struct udevice *dev) > +{ > + struct da8xx_ohci *priv = dev_get_priv(dev); > + int ret; > + > + ret = ohci_deregister(dev); > + if (ret) > + return ret; > + > + ret = usb_cpu_stop(); > + if (ret) > + return ret; > + > + return clk_release_all(priv->clocks, priv->clock_count); > +} > + > +static const struct udevice_id da8xx_ohci_ids[] = { > + { .compatible = "ti,da830-ohci" }, > + { } > +}; > + > +U_BOOT_DRIVER(ohci_generic) = { > + .name = "ohci-da8xx", > + .id = UCLASS_USB, > + .of_match = da8xx_ohci_ids, > + .probe = ohci_da8xx_probe, > + .remove = ohci_da8xx_remove, Add DM_FLAG_OS_PREPARE for this to work IIRC. > + .ops= _usb_ops, > + .priv_auto_alloc_size = sizeof(struct da8xx_ohci), > + .flags = DM_FLAG_ALLOC_PRIV_DMA, > +}; > +#endif > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cyclone5 reboot: warm or cold reset?
Am 30.04.2019 um 21:08 schrieb Marek Vasut: On 4/30/19 8:56 PM, Simon Goldschmidt wrote: Hi all, Hi, I added some of those I think worth discussing this. I was chasing a reboot problem on one of our cyclone5 boards today. That board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures the boot ROM to just jump to OCRAM when rebooting and hope that the SPL is still there and fully working (nothing's overwritten). For a long running production board, this is of course crap, as a pointer running wild could always overwrite the SRAM. But there was not much we could do about it as long as U-Boot and/or Linux were putting out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM unless in 3-byte mode. And while Linux "reboot" could reset the chip into 3-byte mode, "reboot -f" and U-Boot "reset" can't. Now with U-Boot and Linux having everything in place to leave the spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte opcodes, I thought rebooting from Linux would now work with loading the SPL from qspi (by disabling the magic that tells the Boot ROM to jump to OCRAM). Well, if the chip is in the middle of some operation (erase or page program) and you reset the CPU just at the right moment, leaving the chip in 3byte addressing mode won't help you anyway. Right, but unfortunately, that's not an issue for us :-) The only reliable solution is to connect reset to the SPI NOR chip and trigger the reset. Of course, some SPI NORs have a reset line, but it is not connected internally, which is a fantastic design. I think the N25Q256 had exactly such a problem, but only on some revisions, to make it even more messed up. Yeah, well, let's just assume there *are* boards that either use spi-nor chips without a working reset line and there *are* boards with spi-nor chips having a reset line that is just not connected... However, I found the Boot ROM still cannot load the SPL because it tries to load at 100 MHz (while on cold boot, it loads with 6.25 MHz). Look at https://patchwork.ozlabs.org/patch/729738/ Interesting, I didn't know that one. I doesn't seem to have made it into the tree, but it's a different thing slightly: it prevents the Boot ROM jumping to OCRAM, but that's what I did and it still fails as the Boot ROM uses a constant divider "4" resulting in loading SPL with 100 MHz from the qspi chip. And that somehow fails. If I change the handoff files so that the qspi core runs at 200 MHz instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold reset would still be better... However, when triggering cold reset instead of warm reset in rstmgr ctrl register [1], it works fine (and qspi clock is 6.25 MHz). Now the question is: why do we trigger warm reset instead of cold reset? I'd like to know that too. But it's likely because of various AMP setups, where the second CPU or the FPGA do something and you don't want to interrupt that operation by the primary CPU's reset. I haven't seen such deployments much myself though. Ok, from reading the above thread, I guess there might be use cases for the warm reset but not for us. So I can make Linux using cold reset via a Kernel command line parameter but I can't do it for U-Boot. Looks like we need a method to control this for U-Boot. Unless someone comes up with a better explanation, that is. Regards, Simon Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux also uses warm reset by default, but I'm tempted to send a patch for both U-Boot and Linux to use cold reset by default. Any insight on the consequences of using cold reset instead of warm reset would be really appreciated! Regards, Simon [1] https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
On 4/30/19 8:13 PM, Atish Patra wrote: > On 4/30/19 2:52 AM, Marek Vasut wrote: >> On 4/30/19 3:27 AM, Atish Patra wrote: >> >> [...] >> > Yes. FIT image parsing can be done in that way. However, the idea was > here to load Image.gz directly. Image.gz is default compressed Linux > kernel image format in RISC-V. Sigh, and the image header is compressed as well, so there's no way to identify the image format, right ? And there's no decompressor, so the dcompressing has to be done by bootloader, which would need some sort of very smart way of figuring out which exact compression method is used ? >>> Yes. Image.gz is always gunzip. So checking first two bytes is enough to >>> confirm that it is a gz file. >> >> What happens once people start feeding it more exotic compression >> methods, like LZ4 or LZO or LZMA for example ? >> > > booti command help will clearly state that it can only boot kernel from > Image or Image.gz. > > static char booti_help_text[] = > "[addr [initrd[:size]] [fdt]]\n" > - " - boot arm64 Linux Image stored in memory\n" > + " - boot arm64 Linux Image or riscv Linux Image/Image.gz stored > in memory\n" Obvious question -- does this Image.gz stuff apply to arm64 ? > > (I will update the help text with Image.gz part) > > Anything other than that, it will fail with following error. > > "Bad Linux RISCV Image magic!" Right, so we're implementing file(1)-lite here to detect the format. >>> The tricky part is length of the compressed file. I took another look at >>> the gunzip implementation in U-Boot. It looks like to me that compressed >>> header length just to parse the header correctly. It doesn't actually >>> use the "length" to decompress. In fact, it updates the length with >>> uncompressed bytes after the decompression. >> >> That's possible. >> > > David suggested a better idea. > > 1. User can supply kernel_size and we can store in environment variable. > 2. If the size is empty or greater than CONFIG_SYS_BOOTM_LEN, booti > fails with appropriate error message. You can keep decompressing until you reach $bootm_len, sure . > We will update the documents to add the additional step for Image.gz > > I am fine with either approach. Any preference ? > > Regards, > Atish -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cyclone5 reboot: warm or cold reset?
On 4/30/19 8:56 PM, Simon Goldschmidt wrote: > Hi all, Hi, > I added some of those I think worth discussing this. > > I was chasing a reboot problem on one of our cyclone5 boards today. That > board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures > the boot ROM to just jump to OCRAM when rebooting and hope that the SPL > is still there and fully working (nothing's overwritten). > > For a long running production board, this is of course crap, as a > pointer running wild could always overwrite the SRAM. But there was not > much we could do about it as long as U-Boot and/or Linux were putting > out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM > unless in 3-byte mode. And while Linux "reboot" could reset the chip > into 3-byte mode, "reboot -f" and U-Boot "reset" can't. > > Now with U-Boot and Linux having everything in place to leave the > spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte > opcodes, I thought rebooting from Linux would now work with loading the > SPL from qspi (by disabling the magic that tells the Boot ROM to jump to > OCRAM). Well, if the chip is in the middle of some operation (erase or page program) and you reset the CPU just at the right moment, leaving the chip in 3byte addressing mode won't help you anyway. The only reliable solution is to connect reset to the SPI NOR chip and trigger the reset. Of course, some SPI NORs have a reset line, but it is not connected internally, which is a fantastic design. I think the N25Q256 had exactly such a problem, but only on some revisions, to make it even more messed up. > However, I found the Boot ROM still cannot load the SPL because it tries > to load at 100 MHz (while on cold boot, it loads with 6.25 MHz). Look at https://patchwork.ozlabs.org/patch/729738/ > However, when triggering cold reset instead of warm reset in rstmgr ctrl > register [1], it works fine (and qspi clock is 6.25 MHz). > > Now the question is: why do we trigger warm reset instead of cold reset? I'd like to know that too. But it's likely because of various AMP setups, where the second CPU or the FPGA do something and you don't want to interrupt that operation by the primary CPU's reset. I haven't seen such deployments much myself though. > Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux > also uses warm reset by default, but I'm tempted to send a patch for > both U-Boot and Linux to use cold reset by default. > > Any insight on the consequences of using cold reset instead of warm > reset would be really appreciated! > > Regards, > Simon > > [1] > https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
On 4/30/19 4:53 AM, Eugeniu Rosca wrote: The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our platform are always the same. Below is consistent on each cold boot: => ### interrupt autoboot => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc ... uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc ... uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc ... uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc ... uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc ... uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7 While the uuids do change on every 'gpt write' command, the values appear to be taken from the same pool, in the same order. As a user, I expect a trully random uuid value in the above example. Otherwise, system/RFS designers and OS people might assume they have a reliable/consistent uuid passed by the bootloader, while the truth is U-Boot simply lacks entropy to generate a random string. In its first attempt [1] to improve the uuid randomness, this patch updated the seed based on the output of get_timer(), similar to [2]. There are two problems with this approach: - get_timer() has a poor _ms_ resolution - when gen_rand_uuid() is called in a loop, get_timer() returns the same result, leading to the same seed being passed to srand(), leading to the same uuid being generated for several partitions with different names This second patch addresses both drawbacks. My R-Car3 testing [3] consists of running 'gpt write mmc 1 $partitions' in a loop for several minutes collecting 8844 randomly generated UUIDS. Two consecutive cold boots are concatenated in the log. As a result, all uuid values are unique (scripted check). Thanks to Roman, who reported the issue and provided support in fixing. [1] https://patchwork.ozlabs.org/patch/1091802/ [2] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() function") [3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca => while true; do \ env default -a; \ gpt write mmc 1 $partitions; \ print; done Reported-by: Roman Stratiienko Signed-off-by: Eugeniu Rosca This patch may ameliorate the situation for GUIDs a bit. But I dislike: - This patch is a uuid only solution to introduce time ticks as source of entropy. - With timer ticks you possibly introduce very little entropy. - Our random number generator with only 32 state bits remains sub-standard. This is the current situation: net/bootp.c uses the MAC address to seed the random number generator and uses random numbers for defining waits. lib/uuid.c is using it for UUID generation. In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL. Linux uses it for randomizing memory layout. iPXE needs it for secure network connections. This requires a good random number generator with sufficient entropy. We already have implemented a single hardware random number generator in drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA). Many other CPUs come with a hardware random number generator. In Linux's drivers/char/hw_random/ I found, e.g. - meson-rng.c (Amlogic) - mtk-rng.c (MediaTek) - st-rng.c (STMicroelectronics) - imx-rng.c (Freescale) I think we should have a u-class for hardware RNGs as one source of entropy. I would like a random number generator with a high number of state bits (> 127) that we initialize with hardware RNG bits and other sources of entropy. A nice discussion of how Linux does it can be found in [1]. Best regards Heinrich [1] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf --- v2: - Replaced get_timer(0) with get_ticks() and added rand() to seed value - Performed extensive testing on R-Car3 (ARMv8) v1: - https://patchwork.ozlabs.org/patch/1091802/ --- lib/uuid.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/uuid.c b/lib/uuid.c index fa20ee39fc32..2d4d6ef7e461 100644 --- a/lib/uuid.c +++ b/lib/uuid.c @@ -238,6 +238,8 @@ void gen_rand_uuid(unsigned char *uuid_bin) unsigned int *ptr = (unsigned int *) int i; + srand(get_ticks() + rand()); + /* Set all fields randomly */ for (i = 0; i < sizeof(struct uuid) / sizeof(*ptr); i++) *(ptr + i) = cpu_to_be32(rand()); ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] cyclone5 reboot: warm or cold reset?
Hi all, I added some of those I think worth discussing this. I was chasing a reboot problem on one of our cyclone5 boards today. That board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures the boot ROM to just jump to OCRAM when rebooting and hope that the SPL is still there and fully working (nothing's overwritten). For a long running production board, this is of course crap, as a pointer running wild could always overwrite the SRAM. But there was not much we could do about it as long as U-Boot and/or Linux were putting out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM unless in 3-byte mode. And while Linux "reboot" could reset the chip into 3-byte mode, "reboot -f" and U-Boot "reset" can't. Now with U-Boot and Linux having everything in place to leave the spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte opcodes, I thought rebooting from Linux would now work with loading the SPL from qspi (by disabling the magic that tells the Boot ROM to jump to OCRAM). However, I found the Boot ROM still cannot load the SPL because it tries to load at 100 MHz (while on cold boot, it loads with 6.25 MHz). However, when triggering cold reset instead of warm reset in rstmgr ctrl register [1], it works fine (and qspi clock is 6.25 MHz). Now the question is: why do we trigger warm reset instead of cold reset? Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux also uses warm reset by default, but I'm tempted to send a patch for both U-Boot and Linux to use cold reset by default. Any insight on the consequences of using cold reset instead of warm reset would be really appreciated! Regards, Simon [1] https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)
Am 18.04.2019 um 23:08 schrieb Julius Werner: This patch adds support for compressing non-kernel image nodes in a FIT image (kernel nodes could already be compressed previously). This can reduce the size of FIT images and therefore improve boot times (especially when an image bundles many different kernel FDTs). The images will automatically be decompressed on load. This patch does not support extracting compatible strings from compressed FDTs, so it's not very helpful in conjunction with CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments that select the configuration to load explicitly. Signed-off-by: Julius Werner --- common/image-fit.c | 83 +++--- 1 file changed, 49 insertions(+), 34 deletions(-) diff --git a/common/image-fit.c b/common/image-fit.c index ac901e131c..006e828b79 100644 --- a/common/image-fit.c +++ b/common/image-fit.c @@ -22,6 +22,7 @@ DECLARE_GLOBAL_DATA_PTR; #endif /* !USE_HOSTCC*/ +#include #include #include #include @@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void *fdt) kfdt_name); continue; } + + if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) { + debug("Can't extract compat from \"%s\" (compressed)\n", + kfdt_name); + continue; + } + What's this block good for in this patch? Looks like it belongs to 2/2? /* * Get a pointer to this configuration's fdt. */ @@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr, const char *fit_uname_config; const char *fit_base_uname_config; const void *fit; - const void *buf; + void *buf; + void *loadbuf; size_t size; int type_ok, os_ok; - ulong load, data, len; - uint8_t os; + ulong load, load_end, data, len; + uint8_t os, comp; #ifndef USE_HOSTCC uint8_t os_arch; #endif @@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr, images->os.arch = os_arch; #endif - if (image_type == IH_TYPE_FLATDT && - !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) { - puts("FDT image is compressed"); - return -EPROTONOSUPPORT; - } - bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL); type_ok = fit_image_check_type(fit, noffset, image_type) || fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) || @@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr, bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK); /* get image data address and length */ - if (fit_image_get_data_and_size(fit, noffset, , )) { + if (fit_image_get_data_and_size(fit, noffset, + (const void **), )) { printf("Could not find %s subimage data!\n", prop_name); bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA); return -ENOENT; @@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr, #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS) /* perform any post-processing on the image data */ - board_fit_image_post_process((void **), ); + board_fit_image_post_process(, ); #endif len = (ulong)size; - /* verify that image data is a proper FDT blob */ - if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) { - puts("Subimage data is not a FDT"); - return -ENOEXEC; - } - bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK); - /* -* Work-around for eldk-4.2 which gives this warning if we try to -* cast in the unmap_sysmem() call: -* warning: initialization discards qualifiers from pointer target type -*/ - { - void *vbuf = (void *)buf; - - data = map_to_sysmem(vbuf); - } - + data = map_to_sysmem(buf); + load = data; if (load_op == FIT_LOAD_IGNORED) { /* Don't load */ } else if (fit_image_get_load(fit, noffset, )) { @@ -1974,8 +1963,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr, } } else if (load_op != FIT_LOAD_OPTIONAL_NON_ZERO || load) { ulong image_start, image_end; - ulong load_end; - void *dst; /* * move image data to the load address, @@ -1993,14 +1980,42 @@ int fit_image_load(bootm_headers_t *images, ulong addr, printf(" Loading %s from 0x%08lx to 0x%08lx\n", prop_name, data, load); + } - dst = map_sysmem(load, len); - memmove(dst, buf, len); - data = load; +
Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)
Am 30.04.2019 um 06:05 schrieb Simon Goldschmidt: Julius Werner mailto:jwer...@chromium.org>> schrieb am Di., 30. Apr. 2019, 02:38: > However, compared to my above mentioned RFC patch, this here somehow > fails when loading something from the image, e.g. using the cmd 'fpga > loadmk'. Seems like this one doesn't transparently uncompress? It looks to me like do_fpga_loadmk() doesn't actually call fit_load_image()? It calls fit_image_get_data() directly, so it bypasses the code I'm adding. Maybe it should be using fit_load_image() instead, but that's moving pretty far away from what I was trying to do... it could be left for a later patch? Ah, ok. I wasn't aware I had changed that command too :-) let me concentrate on finding out why booting the compressed fit,image doesn't work, then. OK, so it turns out the error was on my side somewhere. I tested this with a known-to-work configuration at work today and it works like a charm, so I'll start to comment the contents of the patch again ;-) 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] RISCV: image: Parse Image.gz support in booti.
On 4/30/19 2:52 AM, Marek Vasut wrote: On 4/30/19 3:27 AM, Atish Patra wrote: [...] Yes. FIT image parsing can be done in that way. However, the idea was here to load Image.gz directly. Image.gz is default compressed Linux kernel image format in RISC-V. Sigh, and the image header is compressed as well, so there's no way to identify the image format, right ? And there's no decompressor, so the dcompressing has to be done by bootloader, which would need some sort of very smart way of figuring out which exact compression method is used ? Yes. Image.gz is always gunzip. So checking first two bytes is enough to confirm that it is a gz file. What happens once people start feeding it more exotic compression methods, like LZ4 or LZO or LZMA for example ? booti command help will clearly state that it can only boot kernel from Image or Image.gz. static char booti_help_text[] = "[addr [initrd[:size]] [fdt]]\n" - "- boot arm64 Linux Image stored in memory\n" + "- boot arm64 Linux Image or riscv Linux Image/Image.gz stored in memory\n" (I will update the help text with Image.gz part) Anything other than that, it will fail with following error. "Bad Linux RISCV Image magic!" The tricky part is length of the compressed file. I took another look at the gunzip implementation in U-Boot. It looks like to me that compressed header length just to parse the header correctly. It doesn't actually use the "length" to decompress. In fact, it updates the length with uncompressed bytes after the decompression. That's possible. David suggested a better idea. 1. User can supply kernel_size and we can store in environment variable. 2. If the size is empty or greater than CONFIG_SYS_BOOTM_LEN, booti fails with appropriate error message. We will update the documents to add the additional step for Image.gz I am fine with either approach. Any preference ? Regards, Atish ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] cmd: gpt: fix and tidy up help message
On 4/30/19 4:53 AM, Eugeniu Rosca wrote: Apply the following changes: - Guard the 'gpt read' command by 'ifdef CONFIG_CMD_GPT_RENAME', since 'gpt read' is not available on CMD_GPT_RENAME=n - Prefix the {read,swap,rename} commands with one space for consistency - Prefix the 'guid' commands with 'gpt' for consistency Signed-off-by: Eugeniu Rosca Reviewed-by: Heinrich Schuchardt Non-related: doc/README.commands describes the preferred way to implement sub-commands. --- cmd/gpt.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/cmd/gpt.c b/cmd/gpt.c index 638870352f40..33cda513969f 100644 --- a/cmd/gpt.c +++ b/cmd/gpt.c @@ -876,21 +876,21 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt, " Example usage:\n" " gpt write mmc 0 $partitions\n" " gpt verify mmc 0 $partitions\n" - " read \n" - "- read GPT into a data structure for manipulation\n" - " guid \n" + " gpt guid \n" "- print disk GUID\n" - " guid \n" + " gpt guid \n" "- set environment variable to disk GUID\n" " Example usage:\n" " gpt guid mmc 0\n" " gpt guid mmc 0 varname\n" #ifdef CONFIG_CMD_GPT_RENAME "gpt partition renaming commands:\n" - "gpt swap\n" + " gpt read \n" + "- read GPT into a data structure for manipulation\n" + " gpt swap\n" "- change all partitions named name1 to name2\n" " and vice-versa\n" - "gpt rename\n" + " gpt rename\n" "- rename the specified partition\n" " Example usage:\n" " gpt swap mmc 0 foo bar\n" ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] disk: efi: Fix memory leak on 'gpt verify'
On 4/30/19 4:53 AM, Eugeniu Rosca wrote: Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt verify mmc 1 No partition list provided - only basic check Verify GPT: success! => ### keep calling 'gpt verify mmc 1' => ### on 58th call, we are out of memory: => gpt verify mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE gpt_verify_headers: *** ERROR: Invalid Backup GPT *** Verify GPT: error! This is caused by calling is_gpt_valid() twice (hence allocating pte also twice via alloc_read_gpt_entries()) while freeing pte only _once_ in the caller of gpt_verify_headers(). Fix that by freeing the pte allocated and populated for primary GPT _before_ allocating and populating the pte for backup GPT. The latter will be freed by the caller of gpt_verify_headers(). With the fix applied, the reproduction scenario [1-2] has been run hundreds of times in a loop w/o running into OOM. [1] gpt verify mmc 1 [2] gpt verify mmc 1 $partitions Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions") Signed-off-by: Eugeniu Rosca Reviewed-by: Heinrich Schuchardt --- disk/part_efi.c | 4 1 file changed, 4 insertions(+) diff --git a/disk/part_efi.c b/disk/part_efi.c index 812d14cdd871..c0fa753339c8 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -698,6 +698,10 @@ int gpt_verify_headers(struct blk_desc *dev_desc, gpt_header *gpt_head, __func__); return -1; } + + /* Free pte before allocating again */ + free(*gpt_pte); + if (is_gpt_valid(dev_desc, (dev_desc->lba - 1), gpt_head, gpt_pte) != 1) { printf("%s: *** ERROR: Invalid Backup GPT ***\n", ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] disk: efi: Fix memory leak on 'gpt guid'
On 4/30/19 4:53 AM, Eugeniu Rosca wrote: Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca Reviewed-by: Heinrich Schuchardt --- disk/part_efi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/disk/part_efi.c b/disk/part_efi.c index 239455b8161e..812d14cdd871 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -209,6 +209,8 @@ int get_disk_guid(struct blk_desc * dev_desc, char *guid) guid_bin = gpt_head->disk_guid.b; uuid_bin_to_str(guid_bin, guid, UUID_STR_FORMAT_GUID); + /* Remember to free pte */ + free(gpt_pte); return 0; } ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting MX6 via Serial Download after DM conversion
Hi Tom, On Mon, Apr 29, 2019 at 2:57 PM Tom Rini wrote: > imx_usb is doing some checking of the second binary it sends along? > That sounds odd to start with, is there some specific history there? My understanding is that imx_usb_loader expects to find a valid IVT entry. After the conversion to DM, a FIT image is used on mx6sabresd_defconfig and such IVT can no longer be found, causing imx_usb_loader to fail to loading u-boot-dtb.img. It would be nice if we can come up with a solution, as loosing the ability to load via imx_usb_loader has a negative impact for users. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.
On Tue, Apr 30, 2019 at 10:02:11AM -0700, Vagrant Cascadian wrote: > On 2019-04-30, Tom Rini wrote: > > On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote: > > > >> Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig. > >> > >> Signed-off-by: Vagrant Cascadian > > > > We need to update include/configs/am335x_evm.h too so that it detects > > this variant and loads the right dtb. > > I believe this was already added in the original commit that added > partial support: > > "findfdt="\ > ... > "if test $board_name = A335PBGL; then " \ > "setenv fdtfile am335x-pocketbeagle.dtb; fi; " \ > > > In my tests, it loaded the correct .dtb file; Is there something I'm > missing? Nope, I missed that it was there, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode
On Tue, 2019-04-30 at 09:20 +0200, Heiko Schocher wrote: > > Am 12.04.2019 um 21:19 schrieb Trent Piepho: > > > These options only apply when not using DM_I2C. When using device > > > trees, the dt will enable and control the speeds of the I2C > > > controller(s) and these configuration options have no effect. > > > > > > So disable them in DM_I2C mode. Otherwise they show up as decoys, and > > > make it look like one is enabling I2C controllers and setting the speed > > > when really it's doing nothing. > arm: + wandboard > +board/wandboard/wandboard.c: In function 'board_init': > +board/wandboard/wandboard.c:466:15: error: 'CONFIG_SYS_MXC_I2C1_SPEED' > undeclared (first use in > this function); did you mean 'CONFIG_SYS_MMC_ENV_DEV'? > + setup_i2c(1, CONFIG_SYS_MXC_I2C1_SPEED, 0x7f, _i2c2_pad_info); > + ^ > + CONFIG_SYS_MMC_ENV_DEV > +board/wandboard/wandboard.c:466:15: note: each undeclared identifier is > reported only once for each > function it appears in > +board/wandboard/wandboard.c:469:16: error: 'CONFIG_SYS_MXC_I2C2_SPEED' > undeclared (first use in > this function); did you mean 'CONFIG_SYS_MXC_I2C1_SPEED'? > + setup_i2c(2, CONFIG_SYS_MXC_I2C2_SPEED, 0x7f, _i2c3_pad_info); > +^ > +CONFIG_SYS_MXC_I2C1_SPEED > +make[2]: *** [board/wandboard/wandboard.o] Error 1 > +make[1]: *** [board/wandboard] Error 2 > +make: *** [sub-make] Error 2 > > Please check. This is caused by a conflict with "imx6: wandboard: convert to DM_I2C", which was applied after I sent my patch. I'm not sure if that commit is correct. Copying Anatolij. It's the only place where non-DM_I2C code uses the kconfig based configuration of I2C. If we look at the code in question: setup_i2c(1, CONFIG_SYS_MXC_I2C1_SPEED, 0x7f, _i2c2_pad_info); Seems a bit odd bus 1 is being configured with i2c*2* pad info? But let's take a look at setup_i2c(). int setup_i2c(unsigned i2c_index, int speed, int slave_addr, struct i2c_pads_info *p) { /* Enable i2c clock */ ret = enable_i2c_clk(1, i2c_index); if (ret) goto err_clk; /* Make sure bus is idle */ ret = force_idle_bus(p); if (ret) goto err_idle; #ifndef CONFIG_DM_I2C bus_i2c_init(i2c_index, speed, slave_addr, force_idle_bus, p); #endif return 0; err_idle: err_clk: gpio_free(p->scl.gp); err_req: gpio_free(p->sda.gp); return ret; } Nothing in the elided section uses "speed". It's only used in the bus_i2c_init() call, and that call is not made when using DM_I2C! So while the wandboard code references CONFIG_SYS_MXC_I2C1_SPEED when using DM_i2C, it's never used by anything. So I believe I'm still correct, even after the wandboard change that CONFIG_SYS_MXC_I2C1_SPEED et al are decoys that aren't used. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards
On 30/04/19 19:08, Jagan Teki wrote: > On Tue, Apr 30, 2019 at 10:30 PM Stefano Babic wrote: >> >> On 30/04/19 18:56, Jagan Teki wrote: >>> Hi Stefano, >>> >>> On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic wrote: Hi Shyam, On 30/04/19 12:33, Shyam Saini wrote: > IMX6 platform has two stage boot loaders like SPL and > U-Boot proper. For each stage we need to burn the image > on to flash with respective offsets. > > This patch create a single image using binman, so that > user can get rid of burning different stage boot images. > > without this patch: > -- > $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 > $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 > > with this patch: > --- > $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 > I am quite confused. There is already a "u-boot-with-spl.imx" target, this works since a lot of time. Which is the reason to duplicate this feature or where is the difference ? >>> >>> At-least I did noticed this now, since it require explicit 'make >>> u-boot-with-spl.bin' I hardly unaware before this been available for >>> i.mx6. >>> >>> But, this binman feature more extensible than the Makefile oriented >>> and the same been adopting by many platforms. May be we can come-up >>> with common solution with binman, what do you think? >> >> First, I would like to avoid to have the same feature implemented >> multiple times in different ways. > > As I said, we didn't know this was supported before since it require > an explicit argument to build..it's our bad. No problem ;-) - there are so many new features / targets in U-Boot, I think I know just a small percentage of them.. ;-) > >> >> If we can get the same solution for all platform, fine. But I guess i.MX >> is not the only one having such as target, socFPGA has the same solution. > > Okay. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards
On Tue, Apr 30, 2019 at 10:30 PM Stefano Babic wrote: > > On 30/04/19 18:56, Jagan Teki wrote: > > Hi Stefano, > > > > On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic wrote: > >> > >> Hi Shyam, > >> > >> On 30/04/19 12:33, Shyam Saini wrote: > >>> IMX6 platform has two stage boot loaders like SPL and > >>> U-Boot proper. For each stage we need to burn the image > >>> on to flash with respective offsets. > >>> > >>> This patch create a single image using binman, so that > >>> user can get rid of burning different stage boot images. > >>> > >>> without this patch: > >>> -- > >>> $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 > >>> $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 > >>> > >>> with this patch: > >>> --- > >>> $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 > >>> > >> > >> I am quite confused. There is already a "u-boot-with-spl.imx" target, > >> this works since a lot of time. Which is the reason to duplicate this > >> feature or where is the difference ? > > > > At-least I did noticed this now, since it require explicit 'make > > u-boot-with-spl.bin' I hardly unaware before this been available for > > i.mx6. > > > > But, this binman feature more extensible than the Makefile oriented > > and the same been adopting by many platforms. May be we can come-up > > with common solution with binman, what do you think? > > First, I would like to avoid to have the same feature implemented > multiple times in different ways. As I said, we didn't know this was supported before since it require an explicit argument to build..it's our bad. > > If we can get the same solution for all platform, fine. But I guess i.MX > is not the only one having such as target, socFPGA has the same solution. Okay. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.
On 2019-04-30, Tom Rini wrote: > On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote: > >> Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig. >> >> Signed-off-by: Vagrant Cascadian > > We need to update include/configs/am335x_evm.h too so that it detects > this variant and loads the right dtb. I believe this was already added in the original commit that added partial support: "findfdt="\ ... "if test $board_name = A335PBGL; then " \ "setenv fdtfile am335x-pocketbeagle.dtb; fi; " \ In my tests, it loaded the correct .dtb file; Is there something I'm missing? live well, vagrant 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] Makefile: Create single image for imx6 socs based boards
On 30/04/19 18:56, Jagan Teki wrote: > Hi Stefano, > > On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic wrote: >> >> Hi Shyam, >> >> On 30/04/19 12:33, Shyam Saini wrote: >>> IMX6 platform has two stage boot loaders like SPL and >>> U-Boot proper. For each stage we need to burn the image >>> on to flash with respective offsets. >>> >>> This patch create a single image using binman, so that >>> user can get rid of burning different stage boot images. >>> >>> without this patch: >>> -- >>> $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 >>> $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 >>> >>> with this patch: >>> --- >>> $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 >>> >> >> I am quite confused. There is already a "u-boot-with-spl.imx" target, >> this works since a lot of time. Which is the reason to duplicate this >> feature or where is the difference ? > > At-least I did noticed this now, since it require explicit 'make > u-boot-with-spl.bin' I hardly unaware before this been available for > i.mx6. > > But, this binman feature more extensible than the Makefile oriented > and the same been adopting by many platforms. May be we can come-up > with common solution with binman, what do you think? First, I would like to avoid to have the same feature implemented multiple times in different ways. If we can get the same solution for all platform, fine. But I guess i.MX is not the only one having such as target, socFPGA has the same solution. Regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards
Hi Stefano, On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic wrote: > > Hi Shyam, > > On 30/04/19 12:33, Shyam Saini wrote: > > IMX6 platform has two stage boot loaders like SPL and > > U-Boot proper. For each stage we need to burn the image > > on to flash with respective offsets. > > > > This patch create a single image using binman, so that > > user can get rid of burning different stage boot images. > > > > without this patch: > > -- > > $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 > > $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 > > > > with this patch: > > --- > > $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 > > > > I am quite confused. There is already a "u-boot-with-spl.imx" target, > this works since a lot of time. Which is the reason to duplicate this > feature or where is the difference ? At-least I did noticed this now, since it require explicit 'make u-boot-with-spl.bin' I hardly unaware before this been available for i.mx6. But, this binman feature more extensible than the Makefile oriented and the same been adopting by many platforms. May be we can come-up with common solution with binman, what do you think? Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: don't use mmc_rd config for other mmc tests
On 4/30/19 5:29 PM, Stephen Warren wrote: > On 4/16/19 4:04 PM, Stephen Warren wrote: >> From: Stephen Warren >> >> Fix test_mmc_dev(), test_mmc_rescan(), test_mmc_info() not to use the >> same configuration data that test_mmc_rd() does. Doing so causes the >> following issues: >> >> * The new code uncondtionally expects certain keys to exist in the >> configuration data. These keys do not exist in existing configuration >> data since they were not previously required, and there was no >> notification re: a requirement to add these new keys. This causes test >> failures due to thrown exceptions when accessing the non-existent keys. >> >> * The new tests logically operate on different objects. test_mmc_rd() >> operates on ranges of sectors on an MMC device (which may be the entire >> set of sectors of a device, or a part of a device), whereas all the new >> tests operate solely on entire devices. These are separate things, and >> it's entirely likely that the user will wish to runs the two types of >> tests on different sets of data; see the example configuration data that >> this commit adds. Ideally, the new tests would have been added to a >> separate Python file, since they aren' closely related to the existing >> tests. >> >> FIXME: Marek, can you please replace the "???" in this patch with some >> reasonable looking data? Thanks. > > Tom, Marek, any chance of applying this? Right now, every mainline > branch is failing 5 tests on every push, which wastes my time having to > go through all the logs to manually check that the failures aren't > anything new/unknown. Thanks. I'm still overloaded, and didn't have time to look into this. But I'm really not fond of the duplication here -- now we have two big tables describing very much the same thing, which SD/MMC to test . -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board: stm32mp1: Update power supply check via USB TYPE-C
Add 2 new checks: - detect when USB TYPE-C cable is not plugged correctly. In this case, GND and VBUS pins are connected but not CC1 and CC2 pins. - detect is an USB Type-C charger supplies more than 3 Amps which is not compliant with the USB Type-C specification In these 2 situations, stop the boot process and let red led blinks forever. V cc1 | V cc2 | power supply | red led | console message range (Volts) |range (Volts)| (Amps) | blinks | --|-|--|-|--- > 2.15| < 0.2 | > 3 | for ever| USB TYPE-C charger not compliant with specification [2.15 - 1.23[ | < 0.2 | 3| NO| NO [1.23 - 0.66[ | < 0.2 | 1.5 | 3 times | WARNING 1.5A power supply detected [0.66 - 0]| < 0.2 | 0.5 | 2 times | WARNING 500mA power supply detected < 0.2 | < 0.2 | | for ever| ERROR USB TYPE-C connection in unattached mode > 0.2 | > 0.2 | | for ever| ERROR USB TYPE-C connection in unattached mode Signed-off-by: Patrice Chotard --- board/st/stm32mp1/stm32mp1.c | 69 +++- 1 file changed, 56 insertions(+), 13 deletions(-) diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c index 76917b0..8c591a5 100644 --- a/board/st/stm32mp1/stm32mp1.c +++ b/board/st/stm32mp1/stm32mp1.c @@ -60,9 +60,10 @@ */ DECLARE_GLOBAL_DATA_PTR; +#define USB_LOW_THRESHOLD_UV 20 #define USB_WARNING_LOW_THRESHOLD_UV 66 #define USB_START_LOW_THRESHOLD_UV 123 -#define USB_START_HIGH_THRESHOLD_UV210 +#define USB_START_HIGH_THRESHOLD_UV215 int checkboard(void) { @@ -263,9 +264,10 @@ static int board_check_usb_power(void) ofnode node; unsigned int raw; int max_uV = 0; + int min_uV = USB_START_HIGH_THRESHOLD_UV; int ret, uV, adc_count; - u8 i, nb_blink; - + u32 nb_blink; + u8 i; node = ofnode_path("/config"); if (!ofnode_valid(node)) { debug("%s: no /config node?\n", __func__); @@ -317,6 +319,8 @@ static int board_check_usb_power(void) if (!adc_raw_to_uV(adc, raw, )) { if (uV > max_uV) max_uV = uV; + if (uV < min_uV) + min_uV = uV; pr_debug("%s: %s[%02d] = %u, %d uV\n", __func__, adc->name, adc_args.args[0], raw, uV); } else { @@ -331,27 +335,66 @@ static int board_check_usb_power(void) * continue. */ if (max_uV > USB_START_LOW_THRESHOLD_UV && - max_uV < USB_START_HIGH_THRESHOLD_UV) + max_uV <= USB_START_HIGH_THRESHOLD_UV && + min_uV <= USB_LOW_THRESHOLD_UV) return 0; - /* Display warning message and make u-boot,error-led blinking */ - pr_err("\n***\n"); + pr_err("\n"); + + /* +* If highest and lowest value are either both below +* USB_LOW_THRESHOLD_UV or both above USB_LOW_THRESHOLD_UV, that +* means USB TYPE-C is in unattached mode, this is an issue, make +* u-boot,error-led blinking and stop boot process. +*/ + if ((max_uV > USB_LOW_THRESHOLD_UV && +min_uV > USB_LOW_THRESHOLD_UV) || +(max_uV <= USB_LOW_THRESHOLD_UV && +min_uV <= USB_LOW_THRESHOLD_UV)) { + pr_err("* ERROR USB TYPE-C connection in unattached mode *\n"); + pr_err("* Check that USB TYPE-C cable is correctly plugged *\n"); + /* with 125ms interval, led will blink for 17.02 years */ + nb_blink = U32_MAX; + } - if (max_uV < USB_WARNING_LOW_THRESHOLD_UV) { - pr_err("* WARNING 500mA power supply detected *\n"); + if (max_uV > USB_LOW_THRESHOLD_UV && + max_uV <= USB_WARNING_LOW_THRESHOLD_UV && + min_uV <= USB_LOW_THRESHOLD_UV) { + pr_err("*WARNING 500mA power supply detected *\n"); nb_blink = 2; - } else { - pr_err("* WARNING 1.5A power supply detected *\n"); + } + + if (max_uV > USB_WARNING_LOW_THRESHOLD_UV && + max_uV <= USB_START_LOW_THRESHOLD_UV && + min_uV <= USB_LOW_THRESHOLD_UV) { + pr_err("* WARNING 1.5mA power supply detected *\n"); nb_blink = 3; } - pr_err("* Current too low, use a 3A power supply! *\n"); - pr_err("***\n\n"); + /* +* If highest value is above 2.15 Volts that means that the USB TypeC +* supplies more than 3 Amp, this is not compliant
[U-Boot] Pull request: u-boot-imx u-boot-imx-20190426
Hi Tom, next chunk of patches, another big chunk will follow. Please pull from u-boot-imx, thanks ! Travis: --- https://travis-ci.org/sbabic/u-boot-imx/builds/524580462 The following changes since commit 3fbd2dce351ab5d40d3244f26bd713caa4f826e2: Merge branch '2019-04-22-master-imports' (2019-04-24 09:04:23 -0400) are available in the Git repository at: git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20190426 for you to fetch changes up to 0d3912fcd41dc2a85891f78e8fc255a379323619: colibri_imx6: use UUID for rootfs (2019-04-25 19:21:40 +0200) Porting to DM and i.MX8 - warp7 to DM - kp_imx53 to DM - Warnings in DT - MX8QM support - colibri-imx6ull to DM - imx7d-pico to DM - ocotp for MX8 Adam Ford (3): ARM: imx6q_logic: Allow optional arguments to cmd line ARM: imx6q_logic: Allow storing environment in FAT on eMMC ARM: omap3_logic: Enable UUID Chris Packham (1): ARM: imx: Fix typo in select option for ZMX25 Filip Brozovic (1): dts: imx6ull: add USB aliases to support DM Gerard Salvatella (1): tdx-cfg-block: add support for new colibri iMX6ull skus Igor Opaniuk (1): colibri_imx6: use UUID for rootfs Joris Offouga (5): Arm: imx7d-pico: Import all Linux device tree for Pico i.MX7D SOM pico-imx7d: defconfig: Add DT file hooks pico-imx7d: defconfig Enable DM gpio pinctrl and pinctrl_imx7 pico-imx7d: Convert DM MMC pico-imx7d: Increase u-boot size for dfu request Ludwig Zenz (2): ARM: imx6: update 1GB DDR3 calibration for DHCOM i.MX6qd PDK ARM: imx6: DHCOM i.MX6 PDK: use Kconfig for inclusion of DDR calibration Lukasz Majewski (14): ARM: Remove HSC|DDC ETH PHY reset code after switching to DM/DTS DTS: Add esdhc3 device tree description tuning for HSC|DDC boards ARM: Enable CONFIG_DM_MMC and CONFIG_DM_BLK on HSC and DDC boards ARM: defconfig: Move CONFIG_FSL_ESDHC to Kconfig ARM: Remove non DM/DTS esdhc3 code from HSC|DDC board related files ARM: kp_imx53: config: Do not use ${boardtype} to setup update wic file DTS: Provide USB host DTS description for i.MX53 devices DTS: Enable USB host support (including regulators) on HSC|DDC boards ARM: Remove EHCI specific code from HSC|DDC board file USB: DM: Convert i.MX5 ehci code to driver model ARM: defconfig: kp_imx53: Enable DM_USB support on HSC|DDC boards ARM: config: Remove not needed CONFIG_MXC_USB_PORT define Convert CONFIG_USB_EHCI_MX5 to Kconfig boot.src: Provide dsa_core.blacklist bootarg when booting via NFS Marcel Ziswiler (16): colibri_vf: fix ethernet by adding explicit phy node colibri_vf: fix tab vs. spaces colibri-imx6ull: fix ethernet phy power on colibri-imx6ull: configuration clean-up colibri-imx6ull: migrate pinctrl and regulators to dtb/dm colibri-imx6ull: migrate mmc to using driver model colibri-imx6ull: migrate usb to using driver model colibri-imx6ull: migrate fec to using driver model ARM: dts: colibri-imx6ull: fix uart-has-rtscts property misc: imx8: remove duplicates from scfw api arm: dts: imx8dx: add lpuart1, lpuart2, lpuart3 board: toradex: tdx-cfg-block: clean-up sku handling board: toradex: tdx-cfg-block: add new skus ARM: dts: i.MX6Q: fix avoid_unnecessary_addr_size warnings ARM: dts: colibri-imx6ull: add osc32k_32k_out pinctrl ARM: dts: colibri-imx6ull: update device tree Parthiban Nallathambi (1): imx: Add variscite DART-6UL Evaluation Kit Peng Fan (19): imx: sip: add call_imx_sip_ret2 imx8: fuse: add fuse driver imx8qxp: mek: Enable CMD_FUSE imx8: mek: move HUSH_PARSER to defconfig imx8qxp: mek: enable dm-spl for pm pinctrl: imx8: add i.MX8QM compatible dt-bindings: pinctrl: add i.MX8QM pads definition dt-bindings: clock: dt-bindings: pinctrl: add i.MX8QM clocks definition arm: dts: introduce dtsi for i.MX8QM imx8: add cpu support clk: imx8: split code into common and soc specific part clk: imx8: add i.MX8QM clk driver imx8: imx8-pins: add i.MX8QM misc: imx8: scu: add i.MX8QM support imx: support i.MX8QM MEK board imx: add lowlevel init for ARM64 imx: 8qxp_mek: fix fdt_file and console imx: i.MX8MQ: clear ocotp error bit ddr: imx8m: hide i.MX8M DDR options from device driver entry Philippe Schenker (1): board: imx6ull: Add disable PMIC_STBY_REQ Pierre-Jean Texier (3): warp7: Fix dfu_alt_info setting after DM conversion warp7: Switch to DM Serial warp7: Switch to DM USB Stefan Agner (3): tdx-cfg-block: simplify i.MX 6 module detection colibri-imx6ull: set module variant depending on config block apalis/colibri_imx6/imx6ull:
[U-Boot] [PATCH 2/3] spi: stm32: Add Serial Peripheral Interface driver for STM32MP
Add SPI driver support for STM32MP SoCs family. Signed-off-by: Patrice Chotard --- MAINTAINERS | 1 + drivers/spi/Kconfig | 8 + drivers/spi/Makefile| 1 + drivers/spi/stm32_spi.c | 615 4 files changed, 625 insertions(+) create mode 100644 drivers/spi/stm32_spi.c diff --git a/MAINTAINERS b/MAINTAINERS index 09f31cd..020dcd2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -311,6 +311,7 @@ F: drivers/ram/stm32mp1/ F: drivers/misc/stm32_rcc.c F: drivers/reset/stm32-reset.c F: drivers/spi/stm32_qspi.c +F: drivers/spi/stm32_spi.c ARM STM STV0991 M: Vikas Manocha diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index fb794ad..49bc940 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -228,6 +228,14 @@ config STM32_QSPI used to access the SPI NOR flash chips on platforms embedding this ST IP core. +config STM32_SPI + bool "STM32 SPI driver" + depends on ARCH_STM32MP + help + Enable the STM32 Serial Peripheral Interface (SPI) driver for STM32MP + SoCs. This uses driver model and requires a device tree binding to + operate. + config TEGRA114_SPI bool "nVidia Tegra114 SPI driver" help diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 8be9a4b..3f9f2fa 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_SPI_SUNXI) += spi-sunxi.o obj-$(CONFIG_SH_SPI) += sh_spi.o obj-$(CONFIG_SH_QSPI) += sh_qspi.o obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o +obj-$(CONFIG_STM32_SPI) += stm32_spi.o obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o obj-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o obj-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o diff --git a/drivers/spi/stm32_spi.c b/drivers/spi/stm32_spi.c new file mode 100644 index 000..34b2175 --- /dev/null +++ b/drivers/spi/stm32_spi.c @@ -0,0 +1,615 @@ +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +/* + * Copyright (C) 2019, STMicroelectronics - All Rights Reserved + * + * Driver for STMicroelectronics Serial peripheral interface (SPI) + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +/* STM32 SPI registers */ +#define STM32_SPI_CR1 0x00 +#define STM32_SPI_CR2 0x04 +#define STM32_SPI_CFG1 0x08 +#define STM32_SPI_CFG2 0x0C +#define STM32_SPI_SR 0x14 +#define STM32_SPI_IFCR 0x18 +#define STM32_SPI_TXDR 0x20 +#define STM32_SPI_RXDR 0x30 +#define STM32_SPI_I2SCFGR 0x50 + +/* STM32_SPI_CR1 bit fields */ +#define SPI_CR1_SPEBIT(0) +#define SPI_CR1_MASRX BIT(8) +#define SPI_CR1_CSTART BIT(9) +#define SPI_CR1_CSUSP BIT(10) +#define SPI_CR1_HDDIR BIT(11) +#define SPI_CR1_SSIBIT(12) + +/* STM32_SPI_CR2 bit fields */ +#define SPI_CR2_TSIZE GENMASK(15, 0) + +/* STM32_SPI_CFG1 bit fields */ +#define SPI_CFG1_DSIZE GENMASK(4, 0) +#define SPI_CFG1_DSIZE_MIN 3 +#define SPI_CFG1_FTHLV_SHIFT 5 +#define SPI_CFG1_FTHLV GENMASK(8, 5) +#define SPI_CFG1_MBR_SHIFT 28 +#define SPI_CFG1_MBR GENMASK(30, 28) +#define SPI_CFG1_MBR_MIN 0 +#define SPI_CFG1_MBR_MAX FIELD_GET(SPI_CFG1_MBR, SPI_CFG1_MBR) + +/* STM32_SPI_CFG2 bit fields */ +#define SPI_CFG2_COMM_SHIFT17 +#define SPI_CFG2_COMM GENMASK(18, 17) +#define SPI_CFG2_MASTERBIT(22) +#define SPI_CFG2_LSBFRST BIT(23) +#define SPI_CFG2_CPHA BIT(24) +#define SPI_CFG2_CPOL BIT(25) +#define SPI_CFG2_SSM BIT(26) +#define SPI_CFG2_AFCNTRBIT(31) + +/* STM32_SPI_SR bit fields */ +#define SPI_SR_RXP BIT(0) +#define SPI_SR_TXP BIT(1) +#define SPI_SR_EOT BIT(3) +#define SPI_SR_TXTFBIT(4) +#define SPI_SR_OVR BIT(6) +#define SPI_SR_SUSPBIT(11) +#define SPI_SR_RXPLVL_SHIFT13 +#define SPI_SR_RXPLVL GENMASK(14, 13) +#define SPI_SR_RXWNE BIT(15) + +/* STM32_SPI_IFCR bit fields */ +#define SPI_IFCR_ALL GENMASK(11, 3) + +/* STM32_SPI_I2SCFGR bit fields */ +#define SPI_I2SCFGR_I2SMOD BIT(0) + +#define MAX_CS_COUNT 4 + +/* SPI Master Baud Rate min/max divisor */ +#define STM32_MBR_DIV_MIN (2 << SPI_CFG1_MBR_MIN) +#define STM32_MBR_DIV_MAX (2 << SPI_CFG1_MBR_MAX) + +#define STM32_SPI_TIMEOUT_US 10 + +/* SPI Communication mode */ +#define SPI_FULL_DUPLEX0 +#define SPI_SIMPLEX_TX 1 +#define SPI_SIMPLEX_RX 2 +#define SPI_HALF_DUPLEX3 + +struct stm32_spi_priv { + void __iomem *base; + struct clk clk; + struct reset_ctl rst_ctl; + struct gpio_desc cs_gpios[MAX_CS_COUNT]; + ulong bus_clk_rate; + unsigned int fifo_size; + unsigned int cur_bpw; + unsigned int cur_hz; +
[U-Boot] [PATCH 3/3] configs: stm32mp15: Enable SPI relative flags
Enable STM32_SPI, SPI, DM_SPI and CMD_SPI flags. This enables the SPI support for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp15_basic_defconfig | 4 configs/stm32mp15_trusted_defconfig | 4 2 files changed, 8 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index bd75df8..1fe7e1d 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -29,6 +29,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SPI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y @@ -68,6 +69,9 @@ CONFIG_DM_REGULATOR_STM32_VREFBUF=y CONFIG_DM_REGULATOR_STPMIC1=y CONFIG_SERIAL_RX_BUFFER=y CONFIG_STM32_SERIAL=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_STM32_SPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index f82b770..f29cd55 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -22,6 +22,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SPI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y @@ -58,6 +59,9 @@ CONFIG_DM_REGULATOR_STM32_VREFBUF=y CONFIG_DM_REGULATOR_STPMIC1=y CONFIG_SERIAL_RX_BUFFER=y CONFIG_STM32_SERIAL=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_STM32_SPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] clk: stm32mp1: Add SPI1 clock entry
Add missing SPI1 clock needed by SPI1 instance. Signed-off-by: Patrice Chotard --- drivers/clk/clk_stm32mp1.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c index 24859fd..800ded7 100644 --- a/drivers/clk/clk_stm32mp1.c +++ b/drivers/clk/clk_stm32mp1.c @@ -90,6 +90,7 @@ #define RCC_PLL4CSGR 0x8A4 #define RCC_I2C12CKSELR0x8C0 #define RCC_I2C35CKSELR0x8C4 +#define RCC_SPI2S1CKSELR 0x8D8 #define RCC_UART6CKSELR0x8E4 #define RCC_UART24CKSELR 0x8E8 #define RCC_UART35CKSELR 0x8EC @@ -298,6 +299,7 @@ enum stm32mp1_parent_sel { _STGEN_SEL, _DSI_SEL, _ADC12_SEL, + _SPI1_SEL, _PARENT_SEL_NB, _UNKNOWN_SEL = 0xff, }; @@ -519,6 +521,7 @@ static const struct stm32mp1_clk_gate stm32mp1_clk_gate[] = { STM32MP1_CLK_SET_CLR(RCC_MP_APB1ENSETR, 23, I2C3_K, _I2C35_SEL), STM32MP1_CLK_SET_CLR(RCC_MP_APB1ENSETR, 24, I2C5_K, _I2C35_SEL), + STM32MP1_CLK_SET_CLR(RCC_MP_APB2ENSETR, 8, SPI1_K, _SPI1_SEL), STM32MP1_CLK_SET_CLR(RCC_MP_APB2ENSETR, 13, USART6_K, _UART6_SEL), STM32MP1_CLK_SET_CLR_F(RCC_MP_APB3ENSETR, 13, VREF, _PCLK3), @@ -589,6 +592,8 @@ static const u8 usbo_parents[] = {_PLL4_R, _USB_PHY_48}; static const u8 stgen_parents[] = {_HSI_KER, _HSE_KER}; static const u8 dsi_parents[] = {_DSI_PHY, _PLL4_P}; static const u8 adc_parents[] = {_PLL4_R, _CK_PER, _PLL3_Q}; +static const u8 spi_parents[] = {_PLL4_P, _PLL3_Q, _I2S_CKIN, _CK_PER, +_PLL3_R}; static const struct stm32mp1_clk_sel stm32mp1_clk_sel[_PARENT_SEL_NB] = { STM32MP1_CLK_PARENT(_I2C12_SEL, RCC_I2C12CKSELR, 0, 0x7, i2c12_parents), @@ -613,6 +618,7 @@ static const struct stm32mp1_clk_sel stm32mp1_clk_sel[_PARENT_SEL_NB] = { STM32MP1_CLK_PARENT(_STGEN_SEL, RCC_STGENCKSELR, 0, 0x3, stgen_parents), STM32MP1_CLK_PARENT(_DSI_SEL, RCC_DSICKSELR, 0, 0x1, dsi_parents), STM32MP1_CLK_PARENT(_ADC12_SEL, RCC_ADCCKSELR, 0, 0x1, adc_parents), + STM32MP1_CLK_PARENT(_SPI1_SEL, RCC_SPI2S1CKSELR, 0, 0x7, spi_parents), }; #ifdef STM32MP1_CLOCK_TREE_INIT @@ -727,6 +733,7 @@ char * const stm32mp1_clk_parent_sel_name[_PARENT_SEL_NB] = { [_STGEN_SEL] = "STGEN", [_DSI_SEL] = "DSI", [_ADC12_SEL] = "ADC12", + [_SPI1_SEL] = "SPI1", }; static const struct stm32mp1_clk_data stm32mp1_data = { -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] Add SPI driver suport for STM32MP1
This series: - adds SPI1 clock entry in clock driver - adds STM32MP1 SPI driver - enables SPI for STM32MP1 Patrice Chotard (3): clk: stm32mp1: Add SPI1 clock entry spi: stm32: Add Serial Peripheral Interface driver for STM32MP configs: stm32mp15: Enable SPI relative flags MAINTAINERS | 1 + configs/stm32mp15_basic_defconfig | 4 + configs/stm32mp15_trusted_defconfig | 4 + drivers/clk/clk_stm32mp1.c | 7 + drivers/spi/Kconfig | 8 + drivers/spi/Makefile| 1 + drivers/spi/stm32_spi.c | 615 7 files changed, 640 insertions(+) create mode 100644 drivers/spi/stm32_spi.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2 v2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped mode, and covers a wide range of hardware. It's hard to change without risking breaking something. I have to tried to be exceedingly detailed in this patch, so please excuse the length of the commit essay that follows. In device mapped mode the I2C xfer function does not handle plain read, and some other, transfers correctly. What it can't handle are transactions that: Start with a read, or, Have a write followed by a read, or, Have more than one read in a row. The common I2C/SMBUS read register and write register transactions always start with a write, followed by a write or a read, and then end. These work, so the bug is not apparent for most I2C slaves that only use these common xfer forms. The existing xfer loop initializes by sending the chip address in write mode after it deals with bus arbitration and master setup. When processing each message, if the next message will be a read, it sends a repeated start followed by the chip address in read mode after the current message. Obviously, this does not work if the first message is a read, as the chip is always addressed in write mode initially by i2c_init_transfer(). A write following a read does not work because the repeated start is only sent when the next message is a read. There is no logic to send it when the current message is a read and next is write. It should be sent every time the bus changes direction. The ability to use a plain read was added to this driver in commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"), but this applied only the non-DM code path. This patch fixes the DM code path. The xfer function will call i2c_init_transfer() with an alen of -1 to avoid sending the chip address. The same way the non-DM code achieves this. The xfer function's message loop will send the address and mode before each message if the bus changes direction, and on the first message. When reading data, the master hardware is one byte ahead of what we receive. I.e., reading a byte from the data register returns a byte *already received* by the master, and causes the master to start the RX of the *next* byte. Therefor, before we read the final byte of a message, we must tell the master what to do next. I add a "last" flag to i2c_read_data() to tell it if the message is to be followed by a stop or a repeated start. When last == true it acts exactly as before. The non-DM code can only create an xfer where the read, if any, is the final message of the xfer. And so the only callsite of i2c_read_data() in the non-DM code has the "last" parameter as true. Therefore, this change has no effect on the non-DM code. As all other changes are in the DM xfer function, which is not even compiled in non-DM code, I am confident that this patch has no effect on boards not using I2C_DM. This greatly reduces the range of hardware that could be affected. For DM boards, I have verified every transaction the "i2c" command can create on a scope and they are all exactly as they are supposed to be. I also tested write->read->write, which isn't possible with the i2c command, and it works as well. I didn't fix multiple reads in a row, as it's a lot more invasive and obviously no one has every wanted them since they've never worked. It didn't seem like the extra complexity was justified to support something no one uses. Cc: Nandor Han Cc: Heiko Schocher Cc: Stefano Babic Cc: Fabio Estevam Cc: Breno Matheus Lima Signed-off-by: Trent Piepho --- Changes from v1: Typo in commit message fixed. Re-sending as base64 to avoid Microsoft email mangling. drivers/i2c/mxc_i2c.c | 95 ++- 1 file changed, 64 insertions(+), 31 deletions(-) diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index f17a47f600..23119cce65 100644 --- a/drivers/i2c/mxc_i2c.c +++ b/drivers/i2c/mxc_i2c.c @@ -482,8 +482,13 @@ static int i2c_write_data(struct mxc_i2c_bus *i2c_bus, u8 chip, const u8 *buf, return ret; } +/* Will generate a STOP after the last byte if "last" is true, i.e. this is the + * final message of a transaction. If not, it switches the bus back to TX mode + * and does not send a STOP, leaving the bus in a state where a repeated start + * and address can be sent for another message. + */ static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, uchar chip, uchar *buf, -int len) +int len, bool last) { int ret; unsigned int temp; @@ -513,17 +518,31 @@ static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, uchar chip, uchar *buf, return ret; } - /* -* It must generate STOP before read I2DR to prevent -* controller from generating another clock cycle -*/ if (i == (len - 1)) { - i2c_imx_stop(i2c_bus); +
[U-Boot] [PATCH 1/2 v2] i2c: mxc_i2c: Document how non-DM functions work
It is not very clear how these work in relation to the exact I2C xfers they produce. In paticular, the address length is somewhat overloaded in the read method. Clearly document the existing behavior. Maybe this will help the next person who needs to work on this driver and not break non-DM boards. Cc: Nandor Han Cc: Heiko Schocher Cc: Stefano Babic Cc: Fabio Estevam Cc: Breno Matheus Lima Signed-off-by: Trent Piepho --- Changes from v1: None, re-sending as base64 to avoid Microsoft email mangling. drivers/i2c/mxc_i2c.c | 34 ++ 1 file changed, 34 insertions(+) diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index 5420afbc8e..f17a47f600 100644 --- a/drivers/i2c/mxc_i2c.c +++ b/drivers/i2c/mxc_i2c.c @@ -540,6 +540,25 @@ static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, uchar chip, uchar *buf, #ifndef CONFIG_DM_I2C /* * Read data from I2C device + * + * The transactions use the syntax defined in the Linux kernel I2C docs. + * + * If alen is > 0, then this function will send a transaction of the form: + * S Chip Wr [A] Addr [A] S Chip Rd [A] [data] A ... NA P + * This is a normal I2C register read: writing the register address, then doing + * a repeated start and reading the data. + * + * If alen == 0, then we get this transaction: + * S Chip Wr [A] S Chip Rd [A] [data] A ... NA P + * This is somewhat unusual, though valid, transaction. It addresses the chip + * in write mode, but doesn't actually write any register address or data, then + * does a repeated start and reads data. + * + * If alen < 0, then we get this transaction: + * S Chip Rd [A] [data] A ... NA P + * The chip is addressed in read mode and then data is read. No register + * address is written first. This is perfectly valid on most devices and + * required on some (usually those that don't act like an array of registers). */ static int bus_i2c_read(struct mxc_i2c_bus *i2c_bus, u8 chip, u32 addr, int alen, u8 *buf, int len) @@ -574,6 +593,20 @@ static int bus_i2c_read(struct mxc_i2c_bus *i2c_bus, u8 chip, u32 addr, /* * Write data to I2C device + * + * If alen > 0, we get this transaction: + *S Chip Wr [A] addr [A] data [A] ... [A] P + * An ordinary write register command. + * + * If alen == 0, then we get this: + *S Chip Wr [A] data [A] ... [A] P + * This is a simple I2C write. + * + * If alen < 0, then we get this: + *S data [A] ... [A] P + * This is most likely NOT something that should be used. It doesn't send the + * chip address first, so in effect, the first byte of data will be used as the + * address. */ static int bus_i2c_write(struct mxc_i2c_bus *i2c_bus, u8 chip, u32 addr, int alen, const u8 *buf, int len) @@ -881,6 +914,7 @@ static int mxc_i2c_probe(struct udevice *bus) return 0; } +/* Sends: S Addr Wr [A|NA] P */ static int mxc_i2c_probe_chip(struct udevice *bus, u32 chip_addr, u32 chip_flags) { -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards
Hi Shyam, On 30/04/19 12:33, Shyam Saini wrote: > IMX6 platform has two stage boot loaders like SPL and > U-Boot proper. For each stage we need to burn the image > on to flash with respective offsets. > > This patch create a single image using binman, so that > user can get rid of burning different stage boot images. > > without this patch: > -- > $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 > $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 > > with this patch: > --- > $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 > I am quite confused. There is already a "u-boot-with-spl.imx" target, this works since a lot of time. Which is the reason to duplicate this feature or where is the difference ? Best regards, Stefano Babic > This would be easily extended to single image creation > for other imx6 soc boards. > > This was tested on engicam imx6qdl and imx6ul boards > > Reviewed-by: Jagan Teki > Signed-off-by: Shyam Saini > --- > Makefile | 10 ++ > arch/arm/dts/imx6-u-boot-binman.dtsi | 16 > arch/arm/dts/imx6qdl-u-boot.dtsi | 1 + > arch/arm/dts/imx6ul-u-boot.dtsi | 1 + > arch/arm/mach-imx/mx6/Kconfig| 2 ++ > doc/imx/common/imx6.txt | 5 + > 6 files changed, 35 insertions(+) > create mode 100644 arch/arm/dts/imx6-u-boot-binman.dtsi > > diff --git a/Makefile b/Makefile > index f2c7bb6041..474271a1d0 100644 > --- a/Makefile > +++ b/Makefile > @@ -851,6 +851,11 @@ ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy) > ALL-y += u-boot-sunxi-with-spl.bin > endif > > +# Build a combined spl + u-boot image for imx6 > +ifeq ($(filter y, $(CONFIG_MX6QDL) > $(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy) > +ALL-$(CONFIG_ARCH_MX6) += u-boot-imx6-with-spl.bin > +endif > + > # enable combined SPL/u-boot/dtb rules for tegra > ifeq ($(CONFIG_TEGRA)$(CONFIG_SPL),yy) > ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin > @@ -1364,6 +1369,11 @@ u-boot-br.bin: u-boot FORCE > endif > endif > > +ifeq ($(filter y, $(CONFIG_MX6QDL) > $(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy) > +u-boot-imx6-with-spl.bin: SPL u-boot-dtb.img FORCE > + @$(call if_changed,binman) > +endif > + > # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including > # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in > # the middle. This is handled by binman based on an image description in the > diff --git a/arch/arm/dts/imx6-u-boot-binman.dtsi > b/arch/arm/dts/imx6-u-boot-binman.dtsi > new file mode 100644 > index 00..fa02d5f61f > --- /dev/null > +++ b/arch/arm/dts/imx6-u-boot-binman.dtsi > @@ -0,0 +1,16 @@ > +#include > + > +/ { > + binman { > + filename = "u-boot-imx6-with-spl.bin"; > + pad-byte = <0xff>; > + > + blob { > + filename = "SPL"; > + }; > + > + u-boot-img { > + offset = ; > + }; > + }; > +}; > diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi > b/arch/arm/dts/imx6qdl-u-boot.dtsi > index 0aa29e38b8..3dfa84dcac 100644 > --- a/arch/arm/dts/imx6qdl-u-boot.dtsi > +++ b/arch/arm/dts/imx6qdl-u-boot.dtsi > @@ -2,6 +2,7 @@ > /* > * Copyright (C) 2018 Jagan Teki > */ > +#include "imx6-u-boot-binman.dtsi" > > / { > soc { > diff --git a/arch/arm/dts/imx6ul-u-boot.dtsi b/arch/arm/dts/imx6ul-u-boot.dtsi > index eb190cf8c8..4e769da0d5 100644 > --- a/arch/arm/dts/imx6ul-u-boot.dtsi > +++ b/arch/arm/dts/imx6ul-u-boot.dtsi > @@ -2,6 +2,7 @@ > /* > * Copyright (C) 2018 Jagan Teki > */ > +#include "imx6-u-boot-binman.dtsi" > > / { > soc { > diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig > index e782859b1e..7de1a00935 100644 > --- a/arch/arm/mach-imx/mx6/Kconfig > +++ b/arch/arm/mach-imx/mx6/Kconfig > @@ -34,6 +34,7 @@ config MX6QDL > bool > select HAS_CAAM > select MX6_SMP > + select BINMAN if SPL && OF_CONTROL > > config MX6S > bool > @@ -57,6 +58,7 @@ config MX6UL > select ROM_UNIFIED_SECTIONS > select SYSCOUNTER_TIMER > select SYS_L2CACHE_OFF > + select BINMAN if SPL && OF_CONTROL > > config MX6UL_LITESOM > bool > diff --git a/doc/imx/common/imx6.txt b/doc/imx/common/imx6.txt > index eab88353f6..5a10f94957 100644 > --- a/doc/imx/common/imx6.txt > +++ b/doc/imx/common/imx6.txt > @@ -88,3 +88,8 @@ Reading bank 4: > > Word 0x0002: 9f027772 0004 > > +2. Single Boot Image > +- > +Write your single imx6 uboot image as: > + > +$ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 > -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email:
Re: [U-Boot] [PATCH 2/4] crypto/fsl: Use __sec_set_jr_context_normal
Hi Bryan, Em ter, 30 de abr de 2019 às 05:13, Bryan O'Donoghue escreveu: > > > > On 30/04/2019 02:28, Bryan O'Donoghue wrote: > > > > > > On 25/04/2019 04:24, Breno Matheus Lima wrote: > >> I couldn't get encrypted boot working in my first attempt, doing the > >> exact same procedure with commit 22191ac35344 ("drivers/crypto/fsl: > >> assign job-rings to non-TrustZone") reverted works fine. > > > > Hi Breno, > > > > I noticed another patch from you re: dek blob, does that address this > > issue for you are is this still a live thing ? No, the patch I have recently submitted does not address the JR TrustZone issue we are currently seeing with DEK blob decapsulation at ROM level. I was not following AN12056 when I tried so I couldn't see this other issue at first moment. > > > > If you are running in secure-world, and the BootROM dek blob stuff > > validates job-ring ownership it _should_ be possible to flip the > > ownership bits to what the BootROM expects and then back again. > > > > If its not working, presumably its because we aren't flipping ownership > > at the right time. > > It occurred to me after I went to bed. > > The right thing to do is leave the BootROM settings up until we hand-off > and then set the required post-boot settings. > > Something I reckon can be ~easily done in some sort of architectural > handover preparation function. > > I'll spin that patchset. Thanks for preparing a second version for this patchset, I see that you have also replied to my other e-mail in "[PATCH 1/4] crypto/fsl: Introduce API to save/restore job-ring context". Your new proposal looks fine to me, I can test again. Thanks, Breno Lima ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode
On Tue, 2019-04-30 at 06:34 +0200, Heiko Schocher wrote: > Hello Trent, > > Am 16.04.2019 um 00:02 schrieb Trent Piepho: > > This is an old driver that supports both device mapped and non-mapped > > mode, and covers a wide range of hardware. It's hard to change without > > risking breaking something. I have to tried to be exceedingly detailed > > in this patch, so please excuse the length of the commit essay that > > follows. > > > Thanks for this work! > > Your patch has > > total: 64 errors, 2 warnings, 0 checks, 145 lines checked > > Please fix and send a v2. > > It would be good to become here some Tested by tags ... > > Reviewed-by: Heiko Schocher My patches are fine before I send them. They are getting DOS line endings added in transit. It seems Microsoft has recently changed their mail server used for office365 to automatically add DOS line endings to all text emails. It didn't use to do this. It seems the only way to avoid this is to use base64 encoding with git send-email. It works went I send a test message to myself and export from Evolution. No way to test if the list software can handle it without re-sending. The patches should be automatically fixed by git am, as it will strip DOS endings by default. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: davinci_emac: use driver model (CONFIG_DM_ETH)
From: Bartosz Golaszewski Add support for CONFIG_DM_ETH to the davinci_emac driver. Optimally we should only support DM-enabled platforms but there are several non-DT boards that still use it so either we need to keep supporting it or drop the boards from u-boot. For now we're stuck with ugly ifdefs. This patch adds support for driver-model to the driver and converts all platforms that use the driver model to selecting CONFIG_DM_ETH. Tested on da850-evm and da850-lcdk. Signed-off-by: Bartosz Golaszewski --- NOTE: I'm currently working on modernizing da850 support in u-boot. This patch is just the first step - I plan on improving the emac driver in general but I'll be OoO until end of next week, so I decided to post it already for reviews. Does anyone know what the status is on boards like twister, ea20 etc. that use davinci_emac, but don't use the driver model? Dropping them would make it easier to clean up this driver. This patch applies on top of my previous series[1]. [1] https://lists.denx.de/pipermail/u-boot/2019-April/367236.html arch/arm/mach-davinci/cpu.c| 13 --- arch/arm/mach-omap2/omap3/emac.c | 3 +- board/davinci/da8xxevm/da850evm.c | 5 -- board/davinci/da8xxevm/omapl138_lcdk.c | 14 board/logicpd/am3517evm/am3517evm.c| 1 - board/ti/ti816x/evm.c | 3 +- configs/am3517_evm_defconfig | 1 + configs/da850_am18xxevm_defconfig | 1 + configs/da850evm_defconfig | 1 + configs/da850evm_direct_nor_defconfig | 1 + configs/omapl138_lcdk_defconfig| 1 + configs/ti816x_evm_defconfig | 1 + drivers/net/ti/davinci_emac.c | 109 + 13 files changed, 100 insertions(+), 54 deletions(-) diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c index f97ad3fc74..9fd6564d04 100644 --- a/arch/arm/mach-davinci/cpu.c +++ b/arch/arm/mach-davinci/cpu.c @@ -5,7 +5,6 @@ */ #include -#include #include #include @@ -90,15 +89,3 @@ int set_cpu_clk_info(void) gd->bd->bi_dsp_freq = 0; return 0; } - -/* - * Initializes on-chip ethernet controllers. - * to override, implement board_eth_init() - */ -int cpu_eth_init(bd_t *bis) -{ -#if defined(CONFIG_DRIVER_TI_EMAC) - davinci_emac_initialize(); -#endif - return 0; -} diff --git a/arch/arm/mach-omap2/omap3/emac.c b/arch/arm/mach-omap2/omap3/emac.c index c79e870183..fb0c9188f5 100644 --- a/arch/arm/mach-omap2/omap3/emac.c +++ b/arch/arm/mach-omap2/omap3/emac.c @@ -7,7 +7,6 @@ */ #include -#include #include #include @@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis) reset &= ~CPGMACSS_SW_RST; writel(reset, _scm_general_regs->ip_sw_reset); - return davinci_emac_initialize(); + return 0; } diff --git a/board/davinci/da8xxevm/da850evm.c b/board/davinci/da8xxevm/da850evm.c index 1bc26828bf..0d2bc5fb32 100644 --- a/board/davinci/da8xxevm/da850evm.c +++ b/board/davinci/da8xxevm/da850evm.c @@ -13,7 +13,6 @@ #include #include #include -#include #include #include #include @@ -472,10 +471,6 @@ int board_eth_init(bd_t *bis) if (rmii_hw_init()) printf("RMII hardware init failed!!!\n"); #endif - if (!davinci_emac_initialize()) { - printf("Error: Ethernet init failed!\n"); - return -1; - } return 0; } diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c b/board/davinci/da8xxevm/omapl138_lcdk.c index 2c2f885d43..ef9656add8 100644 --- a/board/davinci/da8xxevm/omapl138_lcdk.c +++ b/board/davinci/da8xxevm/omapl138_lcdk.c @@ -11,7 +11,6 @@ #include #include #include -#include #include #include #include @@ -229,19 +228,6 @@ int board_init(void) #ifdef CONFIG_DRIVER_TI_EMAC -/* - * Initializes on-board ethernet controllers. - */ -int board_eth_init(bd_t *bis) -{ - if (!davinci_emac_initialize()) { - printf("Error: Ethernet init failed!\n"); - return -1; - } - - return 0; -} - #endif /* CONFIG_DRIVER_TI_EMAC */ #define CFG_MAC_ADDR_SPI_BUS 0 diff --git a/board/logicpd/am3517evm/am3517evm.c b/board/logicpd/am3517evm/am3517evm.c index 10031a4801..bfd4e78274 100644 --- a/board/logicpd/am3517evm/am3517evm.c +++ b/board/logicpd/am3517evm/am3517evm.c @@ -28,7 +28,6 @@ #include #include #include -#include #include "am3517evm.h" DECLARE_GLOBAL_DATA_PTR; diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c index 07a084bab8..240df8cbe1 100644 --- a/board/ti/ti816x/evm.c +++ b/board/ti/ti816x/evm.c @@ -9,7 +9,6 @@ #include #include #include -#include #include #include #include @@ -56,7 +55,7 @@ int board_eth_init(bd_t *bis) printf("Unable to read MAC address. Set \n"); } - return davinci_emac_initialize(); + return 0; } #ifdef CONFIG_SPL_BUILD diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig index
Re: [U-Boot] [PATCH] test/py: don't use mmc_rd config for other mmc tests
On 4/16/19 4:04 PM, Stephen Warren wrote: From: Stephen Warren Fix test_mmc_dev(), test_mmc_rescan(), test_mmc_info() not to use the same configuration data that test_mmc_rd() does. Doing so causes the following issues: * The new code uncondtionally expects certain keys to exist in the configuration data. These keys do not exist in existing configuration data since they were not previously required, and there was no notification re: a requirement to add these new keys. This causes test failures due to thrown exceptions when accessing the non-existent keys. * The new tests logically operate on different objects. test_mmc_rd() operates on ranges of sectors on an MMC device (which may be the entire set of sectors of a device, or a part of a device), whereas all the new tests operate solely on entire devices. These are separate things, and it's entirely likely that the user will wish to runs the two types of tests on different sets of data; see the example configuration data that this commit adds. Ideally, the new tests would have been added to a separate Python file, since they aren' closely related to the existing tests. FIXME: Marek, can you please replace the "???" in this patch with some reasonable looking data? Thanks. Tom, Marek, any chance of applying this? Right now, every mainline branch is failing 5 tests on every push, which wastes my time having to go through all the logs to manually check that the failures aren't anything new/unknown. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] watchdog: stm32mp: Add watchdog driver
This patch adds IWDG (Independent WatchDoG) support for STM32MP platform. Signed-off-by: Christophe Kerello Signed-off-by: Patrice Chotard --- Changes in v2: - Rename timeout variable in timeout_ms in stm32mp_wdt_start() MAINTAINERS| 1 + arch/arm/mach-stm32mp/Kconfig | 1 + drivers/watchdog/Kconfig | 8 +++ drivers/watchdog/Makefile | 1 + drivers/watchdog/stm32mp_wdt.c | 135 + 5 files changed, 146 insertions(+) create mode 100644 drivers/watchdog/stm32mp_wdt.c diff --git a/MAINTAINERS b/MAINTAINERS index 09f31cd..eec2603 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -311,6 +311,7 @@ F: drivers/ram/stm32mp1/ F: drivers/misc/stm32_rcc.c F: drivers/reset/stm32-reset.c F: drivers/spi/stm32_qspi.c +F: drivers/watchdog/stm32mp_wdt.c ARM STM STV0991 M: Vikas Manocha diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig index 73aa382..4e7cc2e 100644 --- a/arch/arm/mach-stm32mp/Kconfig +++ b/arch/arm/mach-stm32mp/Kconfig @@ -17,6 +17,7 @@ config SPL select SPL_DM_RESET select SPL_SERIAL_SUPPORT select SPL_SYSCON + select SPL_WATCHDOG_SUPPORT imply SPL_DISPLAY_PRINT imply SPL_LIBDISK_SUPPORT diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 4a3ff7a..d582abe 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -147,6 +147,14 @@ config WDT_SANDBOX can be probed and supports all of the methods of WDT, but does not really do anything. +config WDT_STM32MP + bool "IWDG watchdog driver for STM32 MP's family" + depends on WDT + imply WATCHDOG + help + Enable the STM32 watchdog (IWDG) driver. Enable support to + configure STM32's on-SoC watchdog. + config XILINX_TB_WATCHDOG bool "Xilinx Axi watchdog timer support" depends on WDT diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 40b2f4b..a3ebff8 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -27,3 +27,4 @@ obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o obj-$(CONFIG_WDT_MTK) += mtk_wdt.o +obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o diff --git a/drivers/watchdog/stm32mp_wdt.c b/drivers/watchdog/stm32mp_wdt.c new file mode 100644 index 000..8093d0a --- /dev/null +++ b/drivers/watchdog/stm32mp_wdt.c @@ -0,0 +1,135 @@ +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +/* + * Copyright (C) 2019, STMicroelectronics - All Rights Reserved + */ + +#include +#include +#include +#include +#include +#include +#include + +/* IWDG registers */ +#define IWDG_KR0x00/* Key register */ +#define IWDG_PR0x04/* Prescaler Register */ +#define IWDG_RLR 0x08/* ReLoad Register */ +#define IWDG_SR0x0C/* Status Register */ + +/* IWDG_KR register bit mask */ +#define KR_KEY_RELOAD 0x /* Reload counter enable */ +#define KR_KEY_ENABLE 0x /* Peripheral enable */ +#define KR_KEY_EWA 0x /* Write access enable */ + +/* IWDG_PR register bit values */ +#define PR_256 0x06/* Prescaler set to 256 */ + +/* IWDG_RLR register values */ +#define RLR_MAX0xFFF /* Max value supported by reload register */ + +/* IWDG_SR register bit values */ +#define SR_PVU BIT(0) /* Watchdog prescaler value update */ +#define SR_RVU BIT(1) /* Watchdog counter reload value update */ + +struct stm32mp_wdt_priv { + fdt_addr_t base;/* registers addr in physical memory */ + unsigned long wdt_clk_rate; /* Watchdog dedicated clock rate */ +}; + +static int stm32mp_wdt_reset(struct udevice *dev) +{ + struct stm32mp_wdt_priv *priv = dev_get_priv(dev); + + writel(KR_KEY_RELOAD, priv->base + IWDG_KR); + + return 0; +} + +static int stm32mp_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) +{ + struct stm32mp_wdt_priv *priv = dev_get_priv(dev); + int reload; + u32 val; + int ret; + + /* Prescaler fixed to 256 */ + reload = timeout_ms * priv->wdt_clk_rate / 256; + if (reload > RLR_MAX + 1) + /* Force to max watchdog counter reload value */ + reload = RLR_MAX + 1; + else if (!reload) + /* Force to min watchdog counter reload value */ + reload = priv->wdt_clk_rate / 256; + + /* Set prescaler & reload registers */ + writel(KR_KEY_EWA, priv->base + IWDG_KR); + writel(PR_256, priv->base + IWDG_PR); + writel(reload - 1, priv->base + IWDG_RLR); + + /* Enable watchdog */ + writel(KR_KEY_ENABLE, priv->base + IWDG_KR); + + /* Wait for the registers to be updated */ + ret = readl_poll_timeout(priv->base + IWDG_SR, val, +val & (SR_PVU |
[U-Boot] [PATCH v2 4/4] configs: stm32mp15: Enable WDT flags
This allows to enable WATCHDOG and WDT flags to be able to reset the watchdog and to support watchdog driver model. Signed-off-by: Patrice Chotard --- Changes in v2: None configs/stm32mp15_basic_defconfig | 2 ++ configs/stm32mp15_trusted_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index fd164fa..7252c14 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -77,3 +77,5 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0483 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_WDT=y +CONFIG_WDT_STM32MP=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index f82b770..52ee280 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -68,3 +68,5 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0483 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_WDT=y +CONFIG_WDT_STM32MP=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] watchdog: Kconfig: Sort entry alphabetically
To make adding new entry easier, sort Kconfig entries in alphabetical order. Signed-off-by: Patrice Chotard Reviewed-by: Stefan Roese --- Changes in v2: None drivers/watchdog/Kconfig | 87 1 file changed, 44 insertions(+), 43 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 3bce0aa..4a3ff7a 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -26,6 +26,13 @@ config BCM2835_WDT This provides basic infrastructure to support BCM2835/2836 watchdog hardware, with a max timeout of ~15secs. +config IMX_WATCHDOG + bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP" + select HW_WATCHDOG + help + Select this to enable the IMX and LSCH2 of Layerscape watchdog + driver. + config OMAP_WATCHDOG bool "TI OMAP watchdog driver" depends on ARCH_OMAP2PLUS @@ -59,14 +66,6 @@ config WDT What exactly happens when the timer expires is up to a particular device/driver. -config WDT_SANDBOX - bool "Enable Watchdog Timer support for Sandbox" - depends on SANDBOX && WDT - help - Enable Watchdog Timer support in Sandbox. This is a dummy device that - can be probed and supports all of the methods of WDT, but does not - really do anything. - config WDT_ARMADA_37XX bool "Marvell Armada 37xx watchdog timer support" depends on WDT && ARMADA_3700 @@ -87,6 +86,13 @@ config WDT_ASPEED It currently does not support Boot Flash Addressing Mode Detection or Second Boot. +config WDT_AT91 + bool "AT91 watchdog timer support" + depends on WDT + help + Select this to enable Microchip watchdog timer, which can be found on + some AT91 devices. + config WDT_BCM6345 bool "BCM6345 watchdog timer support" depends on WDT && (ARCH_BMIPS || ARCH_BCM6858 || ARCH_BCM63158) @@ -95,14 +101,6 @@ config WDT_BCM6345 The watchdog timer is stopped when initialized. It performs full SoC reset. -config WDT_ORION - bool "Orion watchdog timer support" - depends on WDT - select CLK - help - Select this to enable Orion watchdog timer, which can be found on some - Marvell Armada chips. - config WDT_CDNS bool "Cadence watchdog timer support" depends on WDT @@ -111,6 +109,20 @@ config WDT_CDNS Select this to enable Cadence watchdog timer, which can be found on some Xilinx Microzed Platform. +config WDT_MPC8xx + bool "MPC8xx watchdog timer support" + depends on WDT && MPC8xx + select CONFIG_MPC8xx_WATCHDOG + help + Select this to enable mpc8xx watchdog timer + +config WDT_MT7621 + bool "MediaTek MT7621 watchdog timer support" + depends on WDT && ARCH_MT7620 + help + Select this to enable Ralink / Mediatek watchdog timer, + which can be found on some MediaTek chips. + config WDT_MTK bool "MediaTek watchdog timer support" depends on WDT && ARCH_MEDIATEK @@ -119,39 +131,28 @@ config WDT_MTK The watchdog timer is stopped when initialized. It performs full SoC reset. -config XILINX_TB_WATCHDOG - bool "Xilinx Axi watchdog timer support" +config WDT_ORION + bool "Orion watchdog timer support" depends on WDT - imply WATCHDOG + select CLK help - Select this to enable Xilinx Axi watchdog timer, which can be found on some - Xilinx Microblaze Platforms. + Select this to enable Orion watchdog timer, which can be found on some + Marvell Armada chips. -config IMX_WATCHDOG - bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP" - select HW_WATCHDOG +config WDT_SANDBOX + bool "Enable Watchdog Timer support for Sandbox" + depends on SANDBOX && WDT help - Select this to enable the IMX and LSCH2 of Layerscape watchdog - driver. + Enable Watchdog Timer support in Sandbox. This is a dummy device that + can be probed and supports all of the methods of WDT, but does not + really do anything. -config WDT_AT91 - bool "AT91 watchdog timer support" +config XILINX_TB_WATCHDOG + bool "Xilinx Axi watchdog timer support" depends on WDT + imply WATCHDOG help - Select this to enable Microchip watchdog timer, which can be found on - some AT91 devices. - -config WDT_MT7621 - bool "MediaTek MT7621 watchdog timer support" - depends on WDT && ARCH_MT7620 - help - Select this to enable Ralink / Mediatek watchdog timer, - which can be found on some MediaTek chips. - -config WDT_MPC8xx - bool "MPC8xx watchdog timer support" - depends on WDT && MPC8xx - help - Select this to enable mpc8xx
[U-Boot] [PATCH v2 2/4] ARM: dts: stm32mp: Add iwdg2 support for stm32mp157c
This patch adds independent watchdog support for stm32mp157c in SPL. Signed-off-by: Patrice Chotard --- Changes in v2: None arch/arm/dts/stm32mp157-u-boot.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi b/arch/arm/dts/stm32mp157-u-boot.dtsi index ab6f673..09560e2 100644 --- a/arch/arm/dts/stm32mp157-u-boot.dtsi +++ b/arch/arm/dts/stm32mp157-u-boot.dtsi @@ -140,3 +140,7 @@ compatible = "st,stm32-gpio"; u-boot,dm-pre-reloc; }; + + { + u-boot,dm-pre-reloc; +}; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] Add watchdog support for STM32MP1
This series: - sorts Kconfig entries in alphabetical order - enable watchdog support in SPL for STM32MP1 - adds watchdog support to STM32MP1 boards Changes in v2: - Rename timeout variable in timeout_ms in stm32mp_wdt_start() Patrice Chotard (4): watchdog: Kconfig: Sort entry alphabetically ARM: dts: stm32mp: Add iwdg2 support for stm32mp157c watchdog: stm32mp: Add watchdog driver configs: stm32mp15: Enable WDT flags MAINTAINERS | 1 + arch/arm/dts/stm32mp157-u-boot.dtsi | 4 ++ arch/arm/mach-stm32mp/Kconfig | 1 + configs/stm32mp15_basic_defconfig | 2 + configs/stm32mp15_trusted_defconfig | 2 + drivers/watchdog/Kconfig| 91 +--- drivers/watchdog/Makefile | 1 + drivers/watchdog/stm32mp_wdt.c | 135 8 files changed, 196 insertions(+), 41 deletions(-) create mode 100644 drivers/watchdog/stm32mp_wdt.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ti: Add device-tree for am335x-pocketbeagle.
On Mon, Apr 29, 2019 at 04:12:29PM -0700, Vagrant Cascadian wrote: > Add device-tree files from linux 5.1-rc7 needed to complete support > for PocketBeagle. > > Signed-off-by: Vagrant Cascadian Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.
On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote: > Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig. > > Signed-off-by: Vagrant Cascadian We need to update include/configs/am335x_evm.h too so that it detects this variant and loads the right dtb. -- 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] Makefile: Create single image for imx6 socs based boards
Hi Fabio, On Tue, Apr 30, 2019 at 6:17 PM Fabio Estevam wrote: > > Hi Shyam, > > On Tue, Apr 30, 2019 at 7:34 AM Shyam Saini > wrote: > > > > IMX6 platform has two stage boot loaders like SPL and > > U-Boot proper. For each stage we need to burn the image > > on to flash with respective offsets. > > > > This patch create a single image using binman, so that > > user can get rid of burning different stage boot images. > > > > without this patch: > > -- > > $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 > > $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 > > > > with this patch: > > --- > > $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 > > > > This would be easily extended to single image creation > > for other imx6 soc boards. > > > > This was tested on engicam imx6qdl and imx6ul boards > > > > Reviewed-by: Jagan Teki > > Signed-off-by: Shyam Saini > > I like the idea, but this breaks the build for mx6sabresd_defconfig: > > COPYspl/u-boot-spl.bin > CFGSspl/u-boot-spl.cfgout > MKIMAGE SPL > BINMAN u-boot-imx6-with-spl.bin > Wrote map file './image.map' to show errors > binman: Node '/binman/u-boot-img': Offset 0x11000 (69632) overlaps > with previous entry '/binman/blob' ending at 0x11c00 (72704) > Makefile:1374: recipe for target 'u-boot-imx6-with-spl.bin' failed > make: *** [u-boot-imx6-with-spl.bin] Error 1 Look like few of boards are crossing size > 68K which is the default CONFIG_SPL_PAD_TO value. This is the value in sabresd case, ₹ cat image.map ImagePosOffset Size Name 0009c8b8 main-section 00011c00 blob 00011000 0008b8b8 u-boot-img But if this the case the existing u-boot right from board/freescale/mx6sabresd/README $ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 will override the SPL, isn't it? > > I am interested to see if this solution could load > u-boot-imx6-with-spl.bin via imx_usb_loader in Serial Download Mode. > > Currently it is not possible to load SPL + u-boot-dtb.img + FIT via > imx_usb_loader. Does it work with your proposal? Sure, will try. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] crypto/fsl: Introduce API to save/restore job-ring context
On 25/04/2019 23:13, Breno Matheus Lima wrote: Hi Bryan, Em ter, 23 de abr de 2019 às 07:20, Bryan O'Donoghue escreveu: We need to handle the case where DEK blobs are passed to the BootROM. In this case, unlike in HAB authentication the BootROM checks job-ring ownership set to secure world. One possible solution is to set the job-ring ownership to the expected state for DEK blobs and then restore to whatever the run-time wants. For the case where Linux runs in normal-world we would want to set the job-ring ownership to normal-world. The first step in the ownership context switch dance is making an API to do it. This patch introduces: void __weak sec_set_jr_context_secure(void); void __weak sec_set_jr_context_normal(void); This can be over-ridden for a given architecture, as will be necessary for the MPC85xxx Signed-off-by: Bryan O'Donoghue --- drivers/crypto/fsl/jr.c | 38 ++ include/fsl_sec.h | 3 +++ 2 files changed, 41 insertions(+) diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c index cc8d3b02a5..7b13aa4a61 100644 --- a/drivers/crypto/fsl/jr.c +++ b/drivers/crypto/fsl/jr.c @@ -574,6 +574,44 @@ static int rng_init(uint8_t sec_idx) return ret; } #endif + +static void __sec_set_jr_context_secure(uint8_t sec_idx) +{ + ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx); + uint32_t jrown_ns; + int i; + + for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) { + jrown_ns = sec_in32(>jrliodnr[i].ms); + jrown_ns &= ~(JROWN_NS | JRMID_NS); We have the following definition at drivers/crypto/fsl/jr.h: #define JRMID_NS 0x0001 Seems that we are setting JROWN_MID field which is not TrustZone related, from i.MX7D Security Reference Manual: Job Ring Owner's MID. This field defines the MID of the bus master that is permitted to read or write the registers that are specific to a particular Job Ring. These registers include the job ring configuration registers, the interrupt registers, the CAAM Secure Memory Access Permissions and Secure Memory Access Group registers and the ring buffer registers. Hrmm, just seeing your response now Breno. What we have is: include/fsl_sec.h:#define JR_MID2/* Matches ROM configuration */ There's a decent argument to read what the BootROM has set for JR_MID and write it back ... Let me include that in v2. --- bod ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Tidy up some dangling OP-TEE gotchas
On Mon, Apr 29, 2019 at 10:31 PM Bryan O'Donoghue wrote: > > > > On 24/04/2019 01:43, Bryan O'Donoghue wrote: > > Rober P Day rightly pointed out that some odd OP-TEE specific defines were > > appearing in his defconfig, despite not having CONFIG_OPTEE=y set in his > > defconfig. > > Ping, > > Robert, Rui, Fabio - do you guys want changes here ? Looks good to me. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: dts: logicpd-som-lv: Fix MMC1 card detect
The card detect pin was incorrectly using IRQ_TYPE_LEVEL_LOW instead of GPIO_ACTIVE_LOW when reading the state of the CD pin. Without this patch, MMC1 won't be detected. This is the same patch submitted to linux-omap, but I was hoping to get it applied to U-Boot without having to wait for the linux adoption and then backporting. Fixes: 5448ff33f281 ("ARM: DTS: Resync Logic PD SOM-LV 37xx devkit with Linux 4.18-RC4") Signed-off-by: Adam Ford diff --git a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi index 4990ed90dc..3524766515 100644 --- a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi +++ b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi @@ -152,8 +152,8 @@ interrupts-extended = < 83 _pmx_core 0x11a>; pinctrl-names = "default"; pinctrl-0 = <_pins>; - wp-gpios = < 30 GPIO_ACTIVE_HIGH>;/* gpio_126 */ - cd-gpios = < 14 IRQ_TYPE_LEVEL_LOW>; /* gpio_110 */ + wp-gpios = < 30 GPIO_ACTIVE_HIGH>;/* gpio_126 */ + cd-gpios = < 14 GPIO_ACTIVE_LOW>; /* gpio_110 */ vmmc-supply = <>; bus-width = <4>; cap-power-off-card; -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards
Hi Shyam, On Tue, Apr 30, 2019 at 7:34 AM Shyam Saini wrote: > > IMX6 platform has two stage boot loaders like SPL and > U-Boot proper. For each stage we need to burn the image > on to flash with respective offsets. > > This patch create a single image using binman, so that > user can get rid of burning different stage boot images. > > without this patch: > -- > $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 > $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 > > with this patch: > --- > $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 > > This would be easily extended to single image creation > for other imx6 soc boards. > > This was tested on engicam imx6qdl and imx6ul boards > > Reviewed-by: Jagan Teki > Signed-off-by: Shyam Saini I like the idea, but this breaks the build for mx6sabresd_defconfig: COPYspl/u-boot-spl.bin CFGSspl/u-boot-spl.cfgout MKIMAGE SPL BINMAN u-boot-imx6-with-spl.bin Wrote map file './image.map' to show errors binman: Node '/binman/u-boot-img': Offset 0x11000 (69632) overlaps with previous entry '/binman/blob' ending at 0x11c00 (72704) Makefile:1374: recipe for target 'u-boot-imx6-with-spl.bin' failed make: *** [u-boot-imx6-with-spl.bin] Error 1 I am interested to see if this solution could load u-boot-imx6-with-spl.bin via imx_usb_loader in Serial Download Mode. Currently it is not possible to load SPL + u-boot-dtb.img + FIT via imx_usb_loader. Does it work with your proposal? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address
Hi Jeremy, Would you kindly feedback if it's possible to include commit https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932 into U-Boot's patchwork to avoid occasional glitches in the description of U-Boot commits? On Sun, Apr 14, 2019 at 07:39:19PM -0400, Tom Rini wrote: > On Sun, Apr 14, 2019 at 10:13:15PM +0200, Eugeniu Rosca wrote: > > Hi Simon, > > CC: Tom, Yamada-san, Jiri, Stephen, > > > > On Sat, Mar 30, 2019 at 03:19:23PM -0600, Simon Glass wrote: > > > Hi Eugeniu, > > > > > > On Mon, 25 Mar 2019 at 04:44, Eugeniu Rosca wrote: > > > > > > > > Hello Simon, > > > > > > > > On Sun, Mar 10, 2019 at 03:51:47PM -0600, Simon Glass wrote: > > > > [..] > > > > > Reviewed-by: Simon Glass > > > > > > > > Can this fix go to u-boot-dm or is more review required? > > > > > > > > > > Yes it looks like it is in my queue. > > > > > > Regards, > > > Simon > > > > First, many thanks for pushing the fix to u-boot-dm. > > > > Second, I would like to (repeatedly [0]) point out a pretty rare > > corruption of patch metadata, which places the 'Reviewed-by:' > > (and actually any other "*-by: ") signature on top of the '=' > > line if the latter is present in commit description (see [1]). > > > > As Yamada-san pointed out in [0], this is presumably caused by a > > patchwork bug and after some grepping through the patchwork git > > history, it looks like the issue is already fixed in patchwork master > > thanks to Jiri and Stephen via commit [2]. > > > > My guess is that the U-Boot patchwork version might not be containing > > this recent fix, hence still showcasing the wrong behavior? > > > > FWIW, at least below U-Boot commits exhibit the same inconsistency: > > > > u-boot $> for c in $(git log --format=%h --grep "^==="); \ > > do \ > > git log --format=%B -1 $c | grep -B 2 "^===" | \ > > grep -q "by:.*@" && git --no-pager log --oneline -1 $c; \ > > done > > > > 0506620f4f49 sata: sata_mv: Add DM support to enable CONFIG_BLK usage > > 9bfacf249b10 core: ofnode: Fix ASAN-reported stack-buffer-overflow in > > of_get_address > > e1904f4530a3 common: avb_verify: Fix division by zero in mmc_byte_io() > > e91610da7c8a kconfig: re-sync with Linux 4.17-rc4 > > e810565e23cd i.MX6DL: mamoj: Add PFUZE100 support > > dda9892171c3 i.MX6DL: mamoj: Add I2C support > > a0b0ff0ae643 arm: dra7xx: Fix Linux boot from eMMC > > f6d245b8c56c arm: am57xx: Fix Linux boot from eMMC > > 67ff9e11f397 wandboard: move environment partition farther from u-boot.img > > > > [0] https://marc.info/?l=u-boot=152643616902958=2 > > [1] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=9bfacf249b10 > > [2] https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932 > > ("parser: fix parsing of patches with headings") > > Adding in Jeremy since we just use the ozlabs patchwork, thanks! > > -- > Tom -- Best Regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v12 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL
On Tue, Apr 30, 2019 at 2:19 PM Chee, Tien Fong wrote: > > On Sat, 2019-04-27 at 21:50 +0200, Simon Goldschmidt wrote: > > > > On 19.03.19 09:50, tien.fong.c...@intel.com wrote: > > > > > > From: Tien Fong Chee > > > > > > Increasing Malloc pool size up to 0x15000 is required to support > > > FAT in SPL > > > . The result of calculation is come from after applying some few > > > patches > > "Some few patches"? What should that mean? Either you refer to the > > current state or you can refer to the patchwork items. > > > > > > > > which are required for optimizing vfat and maximizing resusable of > > > the > > > memory pool, and then followed by the size required come from > > > default max > > > cluster(0x1) + others(0x2000) + additional memory for > > > headroom(0x3000). > > > Previous records of describing these few patches can be checked > > > from here > > > [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg314511.h > > > tml . > > Why do you refer to mail-archive.com instead of patchwork? > Contains the cover letter in case reviewer need to know more > information. I think you understood that wrong. Why do you reference a 3rd party host (mail-archive.com) instead of the official list archive or patchwork? And please note patchwork keeps the cover letter as well. Also note, this is the commit message which will got into the git lot. Referencing v7 and older history seems misplaced here. Better move it below the '---'. Regards, Simon > > Thanks. > > > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > --- > > > > > > changes for v12 > > > - Improved the commit messages. > > > > > > changes for v11 > > > - No changes. > > > > > > changes for v10 > > > - No changes. > > > > > > changes for v9 > > > - No changes. > > > > > > changes for v8 > > > - Moved the FIT related configs to the patch of configuration for > > > FPGA > > >SoCFPGA A10 SoCDK. > > > > > > changes for v7 > > > - Keep minimal configs. > > > --- > > > include/configs/socfpga_common.h | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/include/configs/socfpga_common.h > > > b/include/configs/socfpga_common.h > > > index 181af9b646..22533036ed 100644 > > > --- a/include/configs/socfpga_common.h > > > +++ b/include/configs/socfpga_common.h > > > @@ -1,6 +1,6 @@ > > > /* SPDX-License-Identifier: GPL-2.0+ */ > > > /* > > > - * Copyright (C) 2012 Altera Corporation > > > + * Copyright (C) 2012-2019 Altera Corporation > > >*/ > > > #ifndef __CONFIG_SOCFPGA_COMMON_H__ > > > #define __CONFIG_SOCFPGA_COMMON_H__ > > > @@ -254,7 +254,7 @@ unsigned int > > > cm_get_qspi_controller_clk_hz(void); > > > #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > > > /* SPL memory allocation configuration, this is for FAT > > > implementation */ > > > #ifndef CONFIG_SYS_SPL_MALLOC_START > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00015000 > > > #define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_INIT_RAM_S > > > IZE - \ > > > CONFIG_SYS_SPL_MALLOC_SI > > > ZE + \ > > > CONFIG_SYS_INIT_RAM_ADDR > > > ) > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v12 5/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On Tue, Apr 30, 2019 at 2:09 PM Chee, Tien Fong wrote: > > On Sat, 2019-04-27 at 21:57 +0200, Simon Goldschmidt wrote: > > > > On 19.03.19 09:50, tien.fong.c...@intel.com wrote: > > > > > > From: Tien Fong Chee > > > > > > Add FPGA driver to support program FPGA with FPGA bitstream loading > > > from > > > filesystem. The driver are designed based on generic firmware > > > loader > > > framework. The driver can handle FPGA program operation from > > > loading FPGA > > > bitstream in flash to memory and then to program FPGA. > > > > > > Signed-off-by: Tien Fong Chee > > > > > > --- > > > > > > changes for v12 > > > - No changes. > > > > > > changes for v11 > > > - No changes. > > > > > > changes for v10 > > > -Cleaned up the codes. > > > -Return -EPERM when programing core on non early IO release mode. > > > > -Using live function to get rid of gd-> > > You got rid of gd-> in v10? How come I see numerous references to it > > below? > > get rid of using gd->fdt_blob for finding the node_offset. > Details in https://patchwork.ozlabs.org/patch/1044415/ Ah, ok. But still, here you're introducing yet more references to gd->fdt_blob. That wouldn't work with a live tree, either, or would it? Regards, Simon > > -/* > - * FPGA Manager to program the FPGA. This is the interface used by > FPGA driver. > - * Return 0 for sucess, non-zero for error. > - */ > +ofnode get_fpga_mgr_ofnode(void) > +{ > + int node_offset; > + > + fdtdec_find_aliases_for_id(gd->fdt_blob, "fpga_mgr", > > nit: using of live functions would be better to get rid of gd->. > > + COMPAT_ALTERA_SOCFPGA_FPGA0, > + _offset, 1); > > Thanks. > > > > > > > > -Removed @0 for fs-loader node > > > > > > changes for v9 > > > - Support data offset > > > - Added default DDR load address > > > - Squashed the image.h > > > - Changed to phandle > > > - Ensure the DDR is fully up running by checking the gd->ram > > > > > > changes for v8 > > > - Added codes to discern bitstream type based on fpga node name. > > > > > > changes for v7 > > > - Restructure the FPGA driver to support both peripheral bitstream > > > and core > > >bitstream bundled into FIT image. > > > - Support loadable property for core bitstream. User can set > > > loadable > > >in DDR for better performance. This loading would be done in one > > > large > > >chunk instead of chunk by chunk loading with small memory > > > buffer. > > > --- > > > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 + > > > .../include/mach/fpga_manager_arria10.h| 39 +- > > > drivers/fpga/socfpga_arria10.c | 497 > > > - > > > include/image.h| 4 + > > > 4 files changed, 542 insertions(+), 15 deletions(-) > > > > > > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > > index 998d811210..cc761967c7 100644 > > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > > @@ -18,6 +18,23 @@ > > > /dts-v1/; > > > #include "socfpga_arria10_socdk.dtsi" > > > > > > +/ { > > > + chosen { > > > + firmware-loader = <_loader0>; > > > + }; > > > + > > > + fs_loader0: fs-loader { > > > + u-boot,dm-pre-reloc; > > > + compatible = "u-boot,fs-loader"; > > > + phandlepart = < 1>; > > > + }; > > > +}; > > > + > > > +_mgr { > > > + u-boot,dm-pre-reloc; > > > + altr,bitstream = "fit_spl_fpga.itb"; > > > +}; > > > + > > >{ > > > u-boot,dm-pre-reloc; > > > status = "okay"; > > > diff --git a/arch/arm/mach- > > > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach- > > > socfpga/include/mach/fpga_manager_arria10.h > > > index 09d13f6fd3..c5f67714aa 100644 > > > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h > > > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h > > > @@ -1,9 +1,13 @@ > > > /* SPDX-License-Identifier: GPL-2.0 */ > > > /* > > > - * Copyright (C) 2017 Intel Corporation > > > + * Copyright (C) 2017-2019 Intel Corporation > > >* All rights reserved. > > >*/ > > > > > > +#include > > > +#include > > > +#include > > > + > > > #ifndef _FPGA_MANAGER_ARRIA10_H_ > > > #define _FPGA_MANAGER_ARRIA10_H_ > > > > > > @@ -51,6 +55,10 @@ > > > #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK > > > BIT(24) > > > #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB > > > 16 > > > > > > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED 0xa65c > > > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d > > > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001 > > > +#define FPGA_SOCFPGA_A10_RBF_CORE 0x8001 > > > #ifndef __ASSEMBLY__ > > > > > > struct socfpga_fpga_manager { > > > @@ -88,12 +96,39 @@ struct socfpga_fpga_manager { > > > u32 imgcfg_fifo_status; > > > }; > > > > > > +enum
Re: [U-Boot] [PATCH] README: davinci: update the documentation for DaVinci
On 30/04/19 2:38 PM, Adam Ford wrote: > On Tue, Apr 30, 2019 at 2:39 AM Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> The DM* family of SOCs is no longer supported. We now support the >> omap-l138 lcdk board and Lego EV3 platform. Reflect those changes > > Don't forget about the da850 EVM Apart from this: Reviewed-by: Sekhar Nori Thanks, Sekhar ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v12 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL
On Sat, 2019-04-27 at 21:50 +0200, Simon Goldschmidt wrote: > > On 19.03.19 09:50, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > Increasing Malloc pool size up to 0x15000 is required to support > > FAT in SPL > > . The result of calculation is come from after applying some few > > patches > "Some few patches"? What should that mean? Either you refer to the > current state or you can refer to the patchwork items. > > > > > which are required for optimizing vfat and maximizing resusable of > > the > > memory pool, and then followed by the size required come from > > default max > > cluster(0x1) + others(0x2000) + additional memory for > > headroom(0x3000). > > Previous records of describing these few patches can be checked > > from here > > [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg314511.h > > tml . > Why do you refer to mail-archive.com instead of patchwork? Contains the cover letter in case reviewer need to know more information. Thanks. > > > > > > > Signed-off-by: Tien Fong Chee > > > > --- > > > > changes for v12 > > - Improved the commit messages. > > > > changes for v11 > > - No changes. > > > > changes for v10 > > - No changes. > > > > changes for v9 > > - No changes. > > > > changes for v8 > > - Moved the FIT related configs to the patch of configuration for > > FPGA > > SoCFPGA A10 SoCDK. > > > > changes for v7 > > - Keep minimal configs. > > --- > > include/configs/socfpga_common.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/include/configs/socfpga_common.h > > b/include/configs/socfpga_common.h > > index 181af9b646..22533036ed 100644 > > --- a/include/configs/socfpga_common.h > > +++ b/include/configs/socfpga_common.h > > @@ -1,6 +1,6 @@ > > /* SPDX-License-Identifier: GPL-2.0+ */ > > /* > > - * Copyright (C) 2012 Altera Corporation > > + * Copyright (C) 2012-2019 Altera Corporation > > */ > > #ifndef __CONFIG_SOCFPGA_COMMON_H__ > > #define __CONFIG_SOCFPGA_COMMON_H__ > > @@ -254,7 +254,7 @@ unsigned int > > cm_get_qspi_controller_clk_hz(void); > > #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > > /* SPL memory allocation configuration, this is for FAT > > implementation */ > > #ifndef CONFIG_SYS_SPL_MALLOC_START > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00015000 > > #define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_INIT_RAM_S > > IZE - \ > > CONFIG_SYS_SPL_MALLOC_SI > > ZE + \ > > CONFIG_SYS_INIT_RAM_ADDR > > ) > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v12 5/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On Sat, 2019-04-27 at 21:57 +0200, Simon Goldschmidt wrote: > > On 19.03.19 09:50, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > Add FPGA driver to support program FPGA with FPGA bitstream loading > > from > > filesystem. The driver are designed based on generic firmware > > loader > > framework. The driver can handle FPGA program operation from > > loading FPGA > > bitstream in flash to memory and then to program FPGA. > > > > Signed-off-by: Tien Fong Chee > > > > --- > > > > changes for v12 > > - No changes. > > > > changes for v11 > > - No changes. > > > > changes for v10 > > -Cleaned up the codes. > > -Return -EPERM when programing core on non early IO release mode. > > > -Using live function to get rid of gd-> > You got rid of gd-> in v10? How come I see numerous references to it > below? get rid of using gd->fdt_blob for finding the node_offset. Details in https://patchwork.ozlabs.org/patch/1044415/ -/* - * FPGA Manager to program the FPGA. This is the interface used by FPGA driver. - * Return 0 for sucess, non-zero for error. - */ +ofnode get_fpga_mgr_ofnode(void) +{ + int node_offset; + + fdtdec_find_aliases_for_id(gd->fdt_blob, "fpga_mgr", nit: using of live functions would be better to get rid of gd->. + COMPAT_ALTERA_SOCFPGA_FPGA0, + _offset, 1); Thanks. > > > > > -Removed @0 for fs-loader node > > > > changes for v9 > > - Support data offset > > - Added default DDR load address > > - Squashed the image.h > > - Changed to phandle > > - Ensure the DDR is fully up running by checking the gd->ram > > > > changes for v8 > > - Added codes to discern bitstream type based on fpga node name. > > > > changes for v7 > > - Restructure the FPGA driver to support both peripheral bitstream > > and core > > bitstream bundled into FIT image. > > - Support loadable property for core bitstream. User can set > > loadable > > in DDR for better performance. This loading would be done in one > > large > > chunk instead of chunk by chunk loading with small memory > > buffer. > > --- > > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 + > > .../include/mach/fpga_manager_arria10.h| 39 +- > > drivers/fpga/socfpga_arria10.c | 497 > > - > > include/image.h| 4 + > > 4 files changed, 542 insertions(+), 15 deletions(-) > > > > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > index 998d811210..cc761967c7 100644 > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts > > @@ -18,6 +18,23 @@ > > /dts-v1/; > > #include "socfpga_arria10_socdk.dtsi" > > > > +/ { > > + chosen { > > + firmware-loader = <_loader0>; > > + }; > > + > > + fs_loader0: fs-loader { > > + u-boot,dm-pre-reloc; > > + compatible = "u-boot,fs-loader"; > > + phandlepart = < 1>; > > + }; > > +}; > > + > > +_mgr { > > + u-boot,dm-pre-reloc; > > + altr,bitstream = "fit_spl_fpga.itb"; > > +}; > > + > > { > > u-boot,dm-pre-reloc; > > status = "okay"; > > diff --git a/arch/arm/mach- > > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach- > > socfpga/include/mach/fpga_manager_arria10.h > > index 09d13f6fd3..c5f67714aa 100644 > > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h > > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h > > @@ -1,9 +1,13 @@ > > /* SPDX-License-Identifier: GPL-2.0 */ > > /* > > - * Copyright (C) 2017 Intel Corporation > > + * Copyright (C) 2017-2019 Intel Corporation > > * All rights reserved. > > */ > > > > +#include > > +#include > > +#include > > + > > #ifndef _FPGA_MANAGER_ARRIA10_H_ > > #define _FPGA_MANAGER_ARRIA10_H_ > > > > @@ -51,6 +55,10 @@ > > #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK > > BIT(24) > > #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB > > 16 > > > > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED 0xa65c > > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d > > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001 > > +#define FPGA_SOCFPGA_A10_RBF_CORE 0x8001 > > #ifndef __ASSEMBLY__ > > > > struct socfpga_fpga_manager { > > @@ -88,12 +96,39 @@ struct socfpga_fpga_manager { > > u32 imgcfg_fifo_status; > > }; > > > > +enum rbf_type { > > + unknown, > > + periph_section, > > + core_section > > +}; > > + > > +enum rbf_security { > > + invalid, > > + unencrypted, > > + encrypted > > +}; > > + > > +struct rbf_info { > > + enum rbf_type section; > > + enum rbf_security security; > > +}; > > + > > +struct fpga_loadfs_info { > > + fpga_fs_info *fpga_fsinfo; > > + u32 remaining; > > + u32 offset; > > + struct rbf_info rbfinfo; > > +}; > > + > >
Re: [U-Boot] [PATCH v12 4/9] ARM: socfpga: Moving the watchdog reset to the for-loop status polling
On Sat, 2019-04-27 at 21:34 +0200, Simon Goldschmidt wrote: > > On 19.03.19 09:50, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > Ensure the watchdog is reset timely on each status polling. > I would have expected a longer commit message here explaining why > this > is done, and from where, where to, and why the watchdog reset has > been > moved. > > Anyway, I don't want to hold back this series again for this, but > please > next time: write longer commit messages. Better write too much than > risk > someone in the future doesn't get what or why you did things. > Noted. Thanks. > > > > > > > Signed-off-by: Tien Fong Chee > > > > --- > > > > changes for v12 > > - Improved the commit messages. > > > > changes for v11 > > - No changes. > > > > changes for v10 > > - This patch was split out from [PATCH v10 5/9] > > ARM: socfpga: Add FPGA drivers for Arria 10 FPGA. > > --- > > drivers/fpga/socfpga_arria10.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/fpga/socfpga_arria10.c > > b/drivers/fpga/socfpga_arria10.c > > index b0abe1955c..9499d1a014 100644 > > --- a/drivers/fpga/socfpga_arria10.c > > +++ b/drivers/fpga/socfpga_arria10.c > > @@ -360,6 +360,7 @@ static int fpgamgr_program_poll_cd(void) > > printf("nstatus == 0 while waiting for > > condone\n"); > > return -EPERM; > > } > > + WATCHDOG_RESET(); > > } > > > > if (i == FPGA_TIMEOUT_CNT) > > @@ -433,7 +434,6 @@ int fpgamgr_program_finish(void) > > printf("FPGA: Poll CD failed with error code > > %d\n", status); > > return -EPERM; > > } > > - WATCHDOG_RESET(); > > > > /* Ensure the FPGA entering user mode */ > > status = fpgamgr_program_poll_usermode(); > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Tidy up some dangling OP-TEE gotchas
Hi Bryan, On Tue 30 Apr 2019 at 02:30, Bryan O'Donoghue wrote: > On 24/04/2019 01:43, Bryan O'Donoghue wrote: >> Rober P Day rightly pointed out that some odd OP-TEE specific defines were >> appearing in his defconfig, despite not having CONFIG_OPTEE=y set in his >> defconfig. > > Ping, > > Robert, Rui, Fabio - do you guys want changes here ? Regarding OPTEE, patches 1/4 and 2/4: Acked-by: Rui Miguel Silva --- Cheers, Rui ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards
IMX6 platform has two stage boot loaders like SPL and U-Boot proper. For each stage we need to burn the image on to flash with respective offsets. This patch create a single image using binman, so that user can get rid of burning different stage boot images. without this patch: -- $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69 with this patch: --- $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 This would be easily extended to single image creation for other imx6 soc boards. This was tested on engicam imx6qdl and imx6ul boards Reviewed-by: Jagan Teki Signed-off-by: Shyam Saini --- Makefile | 10 ++ arch/arm/dts/imx6-u-boot-binman.dtsi | 16 arch/arm/dts/imx6qdl-u-boot.dtsi | 1 + arch/arm/dts/imx6ul-u-boot.dtsi | 1 + arch/arm/mach-imx/mx6/Kconfig| 2 ++ doc/imx/common/imx6.txt | 5 + 6 files changed, 35 insertions(+) create mode 100644 arch/arm/dts/imx6-u-boot-binman.dtsi diff --git a/Makefile b/Makefile index f2c7bb6041..474271a1d0 100644 --- a/Makefile +++ b/Makefile @@ -851,6 +851,11 @@ ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy) ALL-y += u-boot-sunxi-with-spl.bin endif +# Build a combined spl + u-boot image for imx6 +ifeq ($(filter y, $(CONFIG_MX6QDL) $(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy) +ALL-$(CONFIG_ARCH_MX6) += u-boot-imx6-with-spl.bin +endif + # enable combined SPL/u-boot/dtb rules for tegra ifeq ($(CONFIG_TEGRA)$(CONFIG_SPL),yy) ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin @@ -1364,6 +1369,11 @@ u-boot-br.bin: u-boot FORCE endif endif +ifeq ($(filter y, $(CONFIG_MX6QDL) $(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy) +u-boot-imx6-with-spl.bin: SPL u-boot-dtb.img FORCE + @$(call if_changed,binman) +endif + # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in # the middle. This is handled by binman based on an image description in the diff --git a/arch/arm/dts/imx6-u-boot-binman.dtsi b/arch/arm/dts/imx6-u-boot-binman.dtsi new file mode 100644 index 00..fa02d5f61f --- /dev/null +++ b/arch/arm/dts/imx6-u-boot-binman.dtsi @@ -0,0 +1,16 @@ +#include + +/ { + binman { + filename = "u-boot-imx6-with-spl.bin"; + pad-byte = <0xff>; + + blob { + filename = "SPL"; + }; + + u-boot-img { + offset = ; + }; + }; +}; diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi b/arch/arm/dts/imx6qdl-u-boot.dtsi index 0aa29e38b8..3dfa84dcac 100644 --- a/arch/arm/dts/imx6qdl-u-boot.dtsi +++ b/arch/arm/dts/imx6qdl-u-boot.dtsi @@ -2,6 +2,7 @@ /* * Copyright (C) 2018 Jagan Teki */ +#include "imx6-u-boot-binman.dtsi" / { soc { diff --git a/arch/arm/dts/imx6ul-u-boot.dtsi b/arch/arm/dts/imx6ul-u-boot.dtsi index eb190cf8c8..4e769da0d5 100644 --- a/arch/arm/dts/imx6ul-u-boot.dtsi +++ b/arch/arm/dts/imx6ul-u-boot.dtsi @@ -2,6 +2,7 @@ /* * Copyright (C) 2018 Jagan Teki */ +#include "imx6-u-boot-binman.dtsi" / { soc { diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig index e782859b1e..7de1a00935 100644 --- a/arch/arm/mach-imx/mx6/Kconfig +++ b/arch/arm/mach-imx/mx6/Kconfig @@ -34,6 +34,7 @@ config MX6QDL bool select HAS_CAAM select MX6_SMP + select BINMAN if SPL && OF_CONTROL config MX6S bool @@ -57,6 +58,7 @@ config MX6UL select ROM_UNIFIED_SECTIONS select SYSCOUNTER_TIMER select SYS_L2CACHE_OFF + select BINMAN if SPL && OF_CONTROL config MX6UL_LITESOM bool diff --git a/doc/imx/common/imx6.txt b/doc/imx/common/imx6.txt index eab88353f6..5a10f94957 100644 --- a/doc/imx/common/imx6.txt +++ b/doc/imx/common/imx6.txt @@ -88,3 +88,8 @@ Reading bank 4: Word 0x0002: 9f027772 0004 +2. Single Boot Image +- +Write your single imx6 uboot image as: + +$ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1 -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: da850evm: Enable da850-ohci USB host controller
The DA850 EVM has one USB 1.1 OHCI Host controller. With the host controller now support DM_USB, this patch enables the respective functions for the da850evm. Signed-off-by: Adam Ford --- V2: No changes diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig index ee39b0b1bc..1845813b2e 100644 --- a/configs/da850evm_defconfig +++ b/configs/da850evm_defconfig @@ -8,8 +8,8 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x800 CONFIG_SPL_SERIAL_SUPPORT=y -CONFIG_SPL=y CONFIG_NR_DRAM_BANKS=1 +CONFIG_SPL=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y CONFIG_SYS_EXTRA_OPTIONS="MAC_ADDR_IN_SPIFLASH" @@ -67,5 +67,10 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_DAVINCI_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +# CONFIG_SPL_DM_USB is not set +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_DA8XX=y # CONFIG_FAT_WRITE is not set CONFIG_USE_TINY_PRINTF=y diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index 94848f5128..9aaecdd1d5 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -267,6 +267,14 @@ #define CONFIG_ENV_SIZE(16 << 10) #endif +/* USB Configs */ +#define CONFIG_SYS_USB_OHCI_CPU_INIT +#define CONFIG_USB_OHCI_NEW +#define CONFIG_USB_STORAGE +#define CONFIG_SYS_USB_OHCI_REGS_BASE 0x01E25000 +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 15 +#define CONFIG_SYS_USB_OHCI_SLOT_NAME "da850evm" + #ifndef CONFIG_DIRECT_NOR_BOOT /* defines for SPL */ #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_TEXT_BASE - \ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 38/41] clk: add composite clk support
Import clk composite clk support from Linux Kernel 5.1-rc5 Signed-off-by: Peng Fan --- drivers/clk/Kconfig | 14 drivers/clk/Makefile | 1 + drivers/clk/clk-composite.c | 165 +++ include/linux/clk-provider.h | 22 ++ 4 files changed, 202 insertions(+) create mode 100644 drivers/clk/clk-composite.c diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 9df3bc731a..3735e235f5 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -53,6 +53,13 @@ config SPL_CLK_CCF Enable this option if you want to (re-)use the Linux kernel's Common Clock Framework [CCF] code in U-Boot's SPL. +config SPL_CLK_COMPOSITE_CCF + bool "SPL Common Clock Framework [CCF] composite clk support " + depends on SPL_CLK_CCF + help + Enable this option if you want to (re-)use the Linux kernel's Common + Clock Framework [CCF] composite code in U-Boot's SPL. + config CLK_CCF bool "Common Clock Framework [CCF] support " depends on CLK @@ -60,6 +67,13 @@ config CLK_CCF Enable this option if you want to (re-)use the Linux kernel's Common Clock Framework [CCF] code in U-Boot's clock driver. +config CLK_COMPOSITE_CCF + bool "Common Clock Framework [CCF] composite clk support " + depends on CLK_CCF + help + Enable this option if you want to (re-)use the Linux kernel's Common + Clock Framework [CCF] composite code in U-Boot's clock driver. + config CLK_STM32F bool "Enable clock driver support for STM32F family" depends on CLK && (STM32F7 || STM32F4) diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 0bc8f7e5ce..6c71b0fc16 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o clk-gate.o obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o +obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o obj-y += imx/ obj-y += tegra/ diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c new file mode 100644 index 00..18adfd9850 --- /dev/null +++ b/drivers/clk/clk-composite.c @@ -0,0 +1,165 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2013 NVIDIA CORPORATION. All rights reserved. + * Copyright 2019 NXP + */ + +#include +#include +#include +#include +#include +#include +#include + +#include "clk.h" + +#define UBOOT_DM_CLK_COMPOSITE "clk_composite" + +static u8 clk_composite_get_parent(struct clk *clk) +{ + struct clk_composite *composite = to_clk_composite( + clk_dev_binded(clk) ? + (struct clk *)dev_get_driver_data(clk->dev) : clk); + struct clk *mux = composite->mux; + + return clk_mux_get_parent(mux); +} + +static int clk_composite_set_parent(struct clk *clk, struct clk *parent) +{ + struct clk_composite *composite = to_clk_composite( + clk_dev_binded(clk) ? + (struct clk *)dev_get_driver_data(clk->dev) : clk); + const struct clk_ops *mux_ops = composite->mux_ops; + struct clk *mux = composite->mux; + + return mux_ops->set_parent(mux, parent); +} + +static unsigned long clk_composite_recalc_rate(struct clk *clk) +{ + struct clk_composite *composite = to_clk_composite( + clk_dev_binded(clk) ? + (struct clk *)dev_get_driver_data(clk->dev) : clk); + const struct clk_ops *rate_ops = composite->rate_ops; + struct clk *rate = composite->rate; + + return rate_ops->get_rate(rate); +} + +static ulong clk_composite_set_rate(struct clk *clk, unsigned long rate) +{ + struct clk_composite *composite = to_clk_composite( + clk_dev_binded(clk) ? + (struct clk *)dev_get_driver_data(clk->dev) : clk); + const struct clk_ops *rate_ops = composite->rate_ops; + struct clk *clk_rate = composite->rate; + + return rate_ops->set_rate(clk_rate, rate); +} + +static int clk_composite_enable(struct clk *clk) +{ + struct clk_composite *composite = to_clk_composite( + clk_dev_binded(clk) ? + (struct clk *)dev_get_driver_data(clk->dev) : clk); + const struct clk_ops *gate_ops = composite->gate_ops; + struct clk *gate = composite->gate; + + return gate_ops->enable(gate); +} + +static int clk_composite_disable(struct clk *clk) +{ + struct clk_composite *composite = to_clk_composite( + clk_dev_binded(clk) ? + (struct clk *)dev_get_driver_data(clk->dev) : clk); + const struct clk_ops *gate_ops = composite->gate_ops; + struct clk *gate = composite->gate; + + gate_ops->disable(gate); + + return 0; +} + +struct clk_ops clk_composite_ops = { + /* This will be set according to
[U-Boot] [i.MX8MM+CCF 24/41] imx: add get_cpu_rev support for i.MX8MM
There are several variants based on i.MX8MM, add the support in get_cpu_rev Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/soc.c | 57 +++ 1 file changed, 47 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 11251c5f9a..42b99945b4 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -130,25 +130,62 @@ static struct mm_region imx8m_mem_map[] = { struct mm_region *mem_map = imx8m_mem_map; +static u32 get_cpu_variant_type(u32 type) +{ + struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR; + struct fuse_bank *bank = >bank[1]; + struct fuse_bank1_regs *fuse = + (struct fuse_bank1_regs *)bank->fuse_regs; + + u32 value = readl(>tester4); + + if (type == MXC_CPU_IMX8MM) { + switch (value & 0x3) { + case 2: + if (value & 0x1c) + return MXC_CPU_IMX8MMDL; + else + return MXC_CPU_IMX8MMD; + case 3: + if (value & 0x1c) + return MXC_CPU_IMX8MMSL; + else + return MXC_CPU_IMX8MMS; + default: + if (value & 0x1c) + return MXC_CPU_IMX8MML; + break; + } + } + + return type; +} + u32 get_cpu_rev(void) { struct anamix_pll *ana_pll = (struct anamix_pll *)ANATOP_BASE_ADDR; u32 reg = readl(_pll->digprog); u32 type = (reg >> 16) & 0xff; + u32 major_low = (reg >> 8) & 0xff; u32 rom_version; reg &= 0xff; - if (reg == CHIP_REV_1_0) { - /* -* For B0 chip, the DIGPROG is not updated, still TO1.0. -* we have to check ROM version further -*/ - rom_version = readl((void __iomem *)ROM_VERSION_A0); - if (rom_version != CHIP_REV_1_0) { - rom_version = readl((void __iomem *)ROM_VERSION_B0); - if (rom_version >= CHIP_REV_2_0) - reg = CHIP_REV_2_0; + /* i.MX8MM */ + if (major_low == 0x41) { + type = get_cpu_variant_type(MXC_CPU_IMX8MM); + } else { + if (reg == CHIP_REV_1_0) { + /* +* For B0 chip, the DIGPROG is not updated, still TO1.0. +* we have to check ROM version further +*/ + rom_version = readl((void __iomem *)ROM_VERSION_A0); + if (rom_version != CHIP_REV_1_0) { + rom_version = readl((void __iomem *)ROM_VERSION_B0); + if (rom_version >= CHIP_REV_2_0) + reg = CHIP_REV_2_0; + } } } -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] Enable DA830 OHCI USB Controller with DM_USB
This patch enables the DA830 USB Host controller with DM_USB. Adam Ford (2): usb: ohci: ohci-da8xx: Enable da850-ohci driver with DM support ARM: da850evm: Enable da850-ohci USB host controller configs/da850evm_defconfig| 7 +- drivers/usb/host/Kconfig | 5 ++ drivers/usb/host/ohci-da8xx.c | 138 +- include/configs/da850evm.h| 8 ++ 4 files changed, 156 insertions(+), 2 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 28/41] imx8m: soc: probe clk before relocation
probe clk device before relocation to get cpu clk. Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/soc.c | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 42b99945b4..07cda86bdd 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -14,6 +14,10 @@ #include #include #include +#include +#include +#include +#include #include #include #include @@ -277,3 +281,20 @@ void reset_cpu(ulong addr) */ } } + +/* TODO: Add i.MX8MQ */ +#ifdef CONFIG_IMX8MM +int arch_cpu_init_dm(void) +{ + struct udevice *dev; + + uclass_find_first_device(UCLASS_CLK, ); + + for (; dev; uclass_find_next_device()) { + if (device_probe(dev)) + continue; + } + + return 0; +} +#endif -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 30/41] imx: add i.MX8MM PE property
i.MX8MM does not have LVTTL, it has a PE property Signed-off-by: Peng Fan --- arch/arm/include/asm/mach-imx/iomux-v3.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/mach-imx/iomux-v3.h b/arch/arm/include/asm/mach-imx/iomux-v3.h index b899a4ff6f..720e8f7043 100644 --- a/arch/arm/include/asm/mach-imx/iomux-v3.h +++ b/arch/arm/include/asm/mach-imx/iomux-v3.h @@ -104,7 +104,11 @@ typedef u64 iomux_v3_cfg_t; #define PAD_CTL_ODE(0x1 << 5) #define PAD_CTL_PUE(0x1 << 6) #define PAD_CTL_HYS(0x1 << 7) +#ifdef CONFIG_IMX8MM +#define PAD_CTL_PE (0x1 << 8) +#else #define PAD_CTL_LVTTL (0x1 << 8) +#endif #elif defined CONFIG_MX7 -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 35/41] serial: Kconfig: make MXC_UART usable for MX7 and IMX8M
i.MX7 and i.MX8M use mxc uart driver, so let's make the SoC could use MXC_UART kconfig. Signed-off-by: Peng Fan --- drivers/serial/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index fcbb0a81ed..a37b2d60f2 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -561,7 +561,7 @@ config MVEBU_A3700_UART config MXC_UART bool "IMX serial port support" - depends on MX5 || MX6 + depends on MX5 || MX6 || MX7 || IMX8M help If you have a machine based on a Motorola IMX CPU you can enable its onboard serial port by enabling this option. -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 25/41] imx8m: rename clock to clock_imx8mq
i.MX8MQ and i.MX8MM has totally different pll design, so rename clock to clock_imx8mq. Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/Makefile| 3 ++- arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} | 0 2 files changed, 2 insertions(+), 1 deletion(-) rename arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} (100%) diff --git a/arch/arm/mach-imx/imx8m/Makefile b/arch/arm/mach-imx/imx8m/Makefile index feff4941c1..42a1544c6b 100644 --- a/arch/arm/mach-imx/imx8m/Makefile +++ b/arch/arm/mach-imx/imx8m/Makefile @@ -3,4 +3,5 @@ # Copyright 2017 NXP obj-y += lowlevel_init.o -obj-y += clock.o clock_slice.o soc.o +obj-y += clock_slice.o soc.o +obj-$(CONFIG_IMX8MQ) += clock_imx8mq.o diff --git a/arch/arm/mach-imx/imx8m/clock.c b/arch/arm/mach-imx/imx8m/clock_imx8mq.c similarity index 100% rename from arch/arm/mach-imx/imx8m/clock.c rename to arch/arm/mach-imx/imx8m/clock_imx8mq.c -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] usb: ohci: ohci-da8xx: Enable da850-ohci driver with DM support
This patch reuses some former code for the hawkboard, combines it with some some similar DM_USB compatible code for the OHCI driver, and enables the use of the da850's OHCI controller with DM_USB compatibility. Signed-off-by: Adam Ford --- V2: Replace timeout with get_timer and read/modify/write registers with clrsetbits_le32 instead of doing it manually. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 0fbc115801..0d8ab3b651 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -239,6 +239,11 @@ config USB_OHCI_GENERIC ---help--- Enables support for generic OHCI controller. +config USB_OHCI_DA8XX + bool "Support for da850 OHCI USB controller" + help + Enable support for the da850 USB controller. + endif # USB_OHCI_HCD config USB_UHCI_HCD diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c index 47ad3f34d5..e8a495fde5 100644 --- a/drivers/usb/host/ohci-da8xx.c +++ b/drivers/usb/host/ohci-da8xx.c @@ -4,9 +4,54 @@ */ #include - +#include +#include +#include +#include +#include +#include +#include "ohci.h" #include +struct da8xx_ohci { + ohci_t ohci; + struct clk *clocks; /* clock list */ + struct phy phy; + int clock_count;/* number of clock in clock list */ +}; + +static int usb_phy_on(void) +{ + unsigned long timeout; + + clrsetbits_le32(_syscfg_regs->cfgchip2, + (CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN | + CFGCHIP2_OTGPWRDN | CFGCHIP2_OTGMODE | + CFGCHIP2_REFFREQ | CFGCHIP2_USB1PHYCLKMUX), + (CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN | + CFGCHIP2_PHY_PLLON | CFGCHIP2_REFFREQ_24MHZ | + CFGCHIP2_USB2PHYCLKMUX | CFGCHIP2_USB1SUSPENDM)); + + /* wait until the usb phy pll locks */ + timeout = get_timer(0); + while (get_timer(timeout) < 10) { + if (readl(_syscfg_regs->cfgchip2) & CFGCHIP2_PHYCLKGD) + return 1; + } + + /* USB phy was not turned on */ + return 0; +} + +static void usb_phy_off(void) +{ + /* Power down the on-chip PHY. */ + clrsetbits_le32(_syscfg_regs->cfgchip2, + CFGCHIP2_PHY_PLLON | CFGCHIP2_USB1SUSPENDM, + CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN | + CFGCHIP2_RESET); +} + int usb_cpu_init(void) { /* enable psc for usb2.0 */ @@ -37,3 +82,94 @@ int usb_cpu_init_fail(void) { return usb_cpu_stop(); } + +#if CONFIG_IS_ENABLED(DM_USB) +static int ohci_da8xx_probe(struct udevice *dev) +{ + struct ohci_regs *regs = (struct ohci_regs *)devfdt_get_addr(dev); + struct da8xx_ohci *priv = dev_get_priv(dev); + int i, err, ret, clock_nb; + + err = 0; + priv->clock_count = 0; + clock_nb = dev_count_phandle_with_args(dev, "clocks", "#clock-cells"); + if (clock_nb > 0) { + priv->clocks = devm_kcalloc(dev, clock_nb, sizeof(struct clk), + GFP_KERNEL); + if (!priv->clocks) + return -ENOMEM; + + for (i = 0; i < clock_nb; i++) { + err = clk_get_by_index(dev, i, >clocks[i]); + if (err < 0) + break; + + err = clk_enable(>clocks[i]); + if (err) { + dev_err(dev, "failed to enable clock %d\n", i); + clk_free(>clocks[i]); + goto clk_err; + } + priv->clock_count++; + } + } else if (clock_nb != -ENOENT) { + dev_err(dev, "failed to get clock phandle(%d)\n", clock_nb); + return clock_nb; + } + + err = usb_cpu_init(); + + if (err) + goto clk_err; + + err = ohci_register(dev, regs); + if (err) + goto phy_err; + + return 0; + +phy_err: + ret = usb_cpu_stop(); + if (ret) + dev_err(dev, "failed to shutdown usb phy\n"); + +clk_err: + ret = clk_release_all(priv->clocks, priv->clock_count); + if (ret) + dev_err(dev, "failed to disable all clocks\n"); + + return err; +} + +static int ohci_da8xx_remove(struct udevice *dev) +{ + struct da8xx_ohci *priv = dev_get_priv(dev); + int ret; + + ret = ohci_deregister(dev); + if (ret) + return ret; + + ret = usb_cpu_stop(); + if (ret) + return ret; + + return clk_release_all(priv->clocks, priv->clock_count); +} + +static const struct udevice_id da8xx_ohci_ids[] = { + { .compatible = "ti,da830-ohci" }, + { } +}; + +U_BOOT_DRIVER(ohci_generic) = { + .name = "ohci-da8xx", + .id =
[U-Boot] [i.MX8MM+CCF 18/41] imx: add IMX8MQ kconfig entry
Add IMX8MQ kconfig entry, preparing support IMX8MM Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/Kconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig index 317dee9bc1..9c487870a6 100644 --- a/arch/arm/mach-imx/imx8m/Kconfig +++ b/arch/arm/mach-imx/imx8m/Kconfig @@ -4,6 +4,10 @@ config IMX8M bool select ROM_UNIFIED_SECTIONS +config IMX8MQ + bool + select IMX8M + config SYS_SOC default "imx8m" @@ -13,7 +17,7 @@ choice config TARGET_IMX8MQ_EVK bool "imx8mq_evk" - select IMX8M + select IMX8MQ select IMX8M_LPDDR4 endchoice -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 26/41] imx8m: restructure clock.h
i.MX8MQ and i.MX8MM use different analog pll design, but they share same ccm design. Add clock_imx8mq.h for i.MX8MQ keep common part in clock.h Signed-off-by: Peng Fan --- arch/arm/include/asm/arch-imx8m/clock.h| 491 +++-- arch/arm/include/asm/arch-imx8m/clock_imx8mq.h | 424 + arch/arm/mach-imx/imx8m/clock_imx8mq.c | 5 +- 3 files changed, 467 insertions(+), 453 deletions(-) create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h diff --git a/arch/arm/include/asm/arch-imx8m/clock.h b/arch/arm/include/asm/arch-imx8m/clock.h index e7c1670f6b..7225c760fe 100644 --- a/arch/arm/include/asm/arch-imx8m/clock.h +++ b/arch/arm/include/asm/arch-imx8m/clock.h @@ -1,28 +1,29 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright 2017 NXP - * - * Peng Fan + * Copyright 2017-2019 NXP */ -#ifndef _ASM_ARCH_IMX8M_CLOCK_H -#define _ASM_ARCH_IMX8M_CLOCK_H - #include +#ifdef CONFIG_IMX8MQ +#include +#else +#error "Error no clock.h" +#endif + #define MHZ(X) ((X) * 100UL) -enum pll_clocks { - ANATOP_ARM_PLL, - ANATOP_GPU_PLL, - ANATOP_SYSTEM_PLL1, - ANATOP_SYSTEM_PLL2, - ANATOP_SYSTEM_PLL3, - ANATOP_AUDIO_PLL1, - ANATOP_AUDIO_PLL2, - ANATOP_VIDEO_PLL1, - ANATOP_VIDEO_PLL2, - ANATOP_DRAM_PLL, +/* Mainly for compatible to imx common code. */ +enum mxc_clock { + MXC_ARM_CLK = 0, + MXC_IPG_CLK, + MXC_CSPI_CLK, + MXC_ESDHC_CLK, + MXC_ESDHC2_CLK, + MXC_ESDHC3_CLK, + MXC_I2C_CLK, + MXC_UART_CLK, + MXC_QSPI_CLK, }; enum clk_slice_type { @@ -35,297 +36,6 @@ enum clk_slice_type { DRAM_SEL_CLOCK_SLICE, }; -enum clk_root_index { - MXC_ARM_CLK = 0, - ARM_A53_CLK_ROOT= 0, - ARM_M4_CLK_ROOT = 1, - VPU_A53_CLK_ROOT= 2, - GPU_CORE_CLK_ROOT = 3, - GPU_SHADER_CLK_ROOT = 4, - MAIN_AXI_CLK_ROOT = 16, - ENET_AXI_CLK_ROOT = 17, - NAND_USDHC_BUS_CLK_ROOT = 18, - VPU_BUS_CLK_ROOT= 19, - DISPLAY_AXI_CLK_ROOT= 20, - DISPLAY_APB_CLK_ROOT= 21, - DISPLAY_RTRM_CLK_ROOT = 22, - USB_BUS_CLK_ROOT= 23, - GPU_AXI_CLK_ROOT= 24, - GPU_AHB_CLK_ROOT= 25, - NOC_CLK_ROOT= 26, - NOC_APB_CLK_ROOT= 27, - AHB_CLK_ROOT= 32, - IPG_CLK_ROOT= 33, - MXC_IPG_CLK = 33, - AUDIO_AHB_CLK_ROOT = 34, - MIPI_DSI_ESC_RX_CLK_ROOT= 36, - DRAM_SEL_CFG= 48, - CORE_SEL_CFG= 49, - DRAM_ALT_CLK_ROOT = 64, - DRAM_APB_CLK_ROOT = 65, - VPU_G1_CLK_ROOT = 66, - VPU_G2_CLK_ROOT = 67, - DISPLAY_DTRC_CLK_ROOT = 68, - DISPLAY_DC8000_CLK_ROOT = 69, - PCIE1_CTRL_CLK_ROOT = 70, - PCIE1_PHY_CLK_ROOT = 71, - PCIE1_AUX_CLK_ROOT = 72, - DC_PIXEL_CLK_ROOT = 73, - LCDIF_PIXEL_CLK_ROOT= 74, - SAI1_CLK_ROOT = 75, - SAI2_CLK_ROOT = 76, - SAI3_CLK_ROOT = 77, - SAI4_CLK_ROOT = 78, - SAI5_CLK_ROOT = 79, - SAI6_CLK_ROOT = 80, - SPDIF1_CLK_ROOT = 81, - SPDIF2_CLK_ROOT = 82, - ENET_REF_CLK_ROOT = 83, - ENET_TIMER_CLK_ROOT = 84, - ENET_PHY_REF_CLK_ROOT = 85, - NAND_CLK_ROOT = 86, - QSPI_CLK_ROOT = 87, - MXC_ESDHC_CLK = 88, - USDHC1_CLK_ROOT = 88, - MXC_ESDHC2_CLK = 89, - USDHC2_CLK_ROOT = 89, - I2C1_CLK_ROOT = 90, - MXC_I2C_CLK = 90, - I2C2_CLK_ROOT = 91, - I2C3_CLK_ROOT = 92, - I2C4_CLK_ROOT = 93, - UART1_CLK_ROOT = 94, - UART2_CLK_ROOT = 95, - UART3_CLK_ROOT = 96, - UART4_CLK_ROOT = 97, - USB_CORE_REF_CLK_ROOT = 98, - USB_PHY_REF_CLK_ROOT= 99, - GIC_CLK_ROOT= 100, - ECSPI1_CLK_ROOT = 101, - ECSPI2_CLK_ROOT = 102, - PWM1_CLK_ROOT = 103, - PWM2_CLK_ROOT = 104, - PWM3_CLK_ROOT = 105, - PWM4_CLK_ROOT
[U-Boot] [i.MX8MM+CCF 31/41] imx8m: Fix MMU table issue for OPTEE memory
When running with OPTEE, the MMU table in u-boot does not remove the OPTEE memory from its settings. So ARM speculative prefetch in u-boot may access that OPTEE memory. Due to trust zone is enabled by OPTEE and that memory is set to secure access, then the speculative prefetch will fail and cause various memory issue in u-boot. The fail address register and int_status register in trustzone has logged that speculative access from u-boot. Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/soc.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 07cda86bdd..5e9481c565 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -116,16 +116,18 @@ static struct mm_region imx8m_mem_map[] = { /* DRAM1 */ .virt = 0x4000UL, .phys = 0x4000UL, - .size = 0xC000UL, + .size = PHYS_SDRAM_SIZE, .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_OUTER_SHARE +#ifdef PHYS_SDRAM_2_SIZE }, { /* DRAM2 */ .virt = 0x1UL, .phys = 0x1UL, - .size = 0x04000UL, + .size = PHYS_SDRAM_2_SIZE, .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_OUTER_SHARE +#endif }, { /* List terminator */ 0, @@ -134,6 +136,20 @@ static struct mm_region imx8m_mem_map[] = { struct mm_region *mem_map = imx8m_mem_map; +void enable_caches(void) +{ + /* +* If OPTEE runs, remove OPTEE memory from MMU table to +* avoid speculative prefetch. OPTEE runs at the top of +* the first memory bank +*/ + if (rom_pointer[1]) + imx8m_mem_map[5].size -= rom_pointer[1]; + + icache_enable(); + dcache_enable(); +} + static u32 get_cpu_variant_type(u32 type) { struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR; -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 21/41] imx: add i.MX8MM cpu type
Add i.MX8MM cpu type and related helper functions Signed-off-by: Peng Fan --- arch/arm/include/asm/arch-imx/cpu.h | 6 ++ arch/arm/include/asm/mach-imx/sys_proto.h | 8 arch/arm/mach-imx/cpu.c | 12 3 files changed, 26 insertions(+) diff --git a/arch/arm/include/asm/arch-imx/cpu.h b/arch/arm/include/asm/arch-imx/cpu.h index 667badbc06..fab530e324 100644 --- a/arch/arm/include/asm/arch-imx/cpu.h +++ b/arch/arm/include/asm/arch-imx/cpu.h @@ -25,6 +25,12 @@ #define MXC_CPU_MX7S 0x71 /* dummy ID */ #define MXC_CPU_MX7D 0x72 #define MXC_CPU_IMX8MQ 0x82 +#define MXC_CPU_IMX8MM 0x85 /* dummy ID */ +#define MXC_CPU_IMX8MML0x86 /* dummy ID */ +#define MXC_CPU_IMX8MMD0x87 /* dummy ID */ +#define MXC_CPU_IMX8MMDL 0x88 /* dummy ID */ +#define MXC_CPU_IMX8MMS0x89 /* dummy ID */ +#define MXC_CPU_IMX8MMSL 0x8a /* dummy ID */ #define MXC_CPU_IMX8QXP_A0 0x90 /* dummy ID */ #define MXC_CPU_IMX8QXP0x92 /* dummy ID */ #define MXC_CPU_MX7ULP 0xE1 /* Temporally hard code */ diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h b/arch/arm/include/asm/mach-imx/sys_proto.h index d0f866b630..88927aeb6b 100644 --- a/arch/arm/include/asm/mach-imx/sys_proto.h +++ b/arch/arm/include/asm/mach-imx/sys_proto.h @@ -43,6 +43,14 @@ #define is_mx7ulp() (is_cpu_type(MXC_CPU_MX7ULP)) #define is_imx8mq() (is_cpu_type(MXC_CPU_IMX8MQ)) +#define is_imx8mm() (is_cpu_type(MXC_CPU_IMX8MM) || is_cpu_type(MXC_CPU_IMX8MML) ||\ + is_cpu_type(MXC_CPU_IMX8MMD) || is_cpu_type(MXC_CPU_IMX8MMDL) || \ + is_cpu_type(MXC_CPU_IMX8MMS) || is_cpu_type(MXC_CPU_IMX8MMSL)) +#define is_imx8mml() (is_cpu_type(MXC_CPU_IMX8MML)) +#define is_imx8mmd() (is_cpu_type(MXC_CPU_IMX8MMD)) +#define is_imx8mmdl() (is_cpu_type(MXC_CPU_IMX8MMDL)) +#define is_imx8mms() (is_cpu_type(MXC_CPU_IMX8MMS)) +#define is_imx8mmsl() (is_cpu_type(MXC_CPU_IMX8MMSL)) #define is_imx8qxp() (is_cpu_type(MXC_CPU_IMX8QXP)) #ifdef CONFIG_MX6 diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c index 6b83f92662..14370929de 100644 --- a/arch/arm/mach-imx/cpu.c +++ b/arch/arm/mach-imx/cpu.c @@ -145,6 +145,18 @@ unsigned imx_ddr_size(void) const char *get_imx_type(u32 imxtype) { switch (imxtype) { + case MXC_CPU_IMX8MM: + return "8MMQ"; /* Quad-core version of the imx8mm */ + case MXC_CPU_IMX8MML: + return "8MMQL"; /* Quad-core Lite version of the imx8mm */ + case MXC_CPU_IMX8MMD: + return "8MMD"; /* Dual-core version of the imx8mm */ + case MXC_CPU_IMX8MMDL: + return "8MMDL"; /* Dual-core Lite version of the imx8mm */ + case MXC_CPU_IMX8MMS: + return "8MMS"; /* Single-core version of the imx8mm */ + case MXC_CPU_IMX8MMSL: + return "8MMSL"; /* Single-core Lite version of the imx8mm */ case MXC_CPU_IMX8MQ: return "8MQ"; /* Quad-core version of the imx8m */ case MXC_CPU_MX7S: -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 40/41] clk: imx: add i.MX8MM clk driver
Add i.MX8MM clk driver support. Signed-off-by: Peng Fan --- drivers/clk/imx/Makefile | 1 + drivers/clk/imx/clk-imx8mm.c | 415 +++ 2 files changed, 416 insertions(+) create mode 100644 drivers/clk/imx/clk-imx8mm.c diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index beba3bff39..e8cac4127a 100644 --- a/drivers/clk/imx/Makefile +++ b/drivers/clk/imx/Makefile @@ -5,3 +5,4 @@ obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-gate2.o clk-pllv3.o clk-pfd.o obj-$(CONFIG_CLK_IMX6Q) += clk-imx6q.o obj-$(CONFIG_CLK_IMX8) += clk-imx8.o +obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o clk-pll14xx.o clk-composite-8m.o diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c new file mode 100644 index 00..329fd8ed06 --- /dev/null +++ b/drivers/clk/imx/clk-imx8mm.c @@ -0,0 +1,415 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright 2019 NXP + * Peng Fan + */ + +#include +#include +#include +#include +#include +#include +#include + +#include "clk.h" + +#define PLL_1416X_RATE(_rate, _m, _p, _s) \ + { \ + .rate = (_rate),\ + .mdiv = (_m), \ + .pdiv = (_p), \ + .sdiv = (_s), \ + } + +#define PLL_1443X_RATE(_rate, _m, _p, _s, _k) \ + { \ + .rate = (_rate),\ + .mdiv = (_m), \ + .pdiv = (_p), \ + .sdiv = (_s), \ + .kdiv = (_k), \ + } + +static const struct imx_pll14xx_rate_table imx8mm_pll1416x_tbl[] = { + PLL_1416X_RATE(18U, 225, 3, 0), + PLL_1416X_RATE(16U, 200, 3, 0), + PLL_1416X_RATE(12U, 300, 3, 1), + PLL_1416X_RATE(10U, 250, 3, 1), + PLL_1416X_RATE(8U, 200, 3, 1), + PLL_1416X_RATE(75000U, 250, 2, 2), + PLL_1416X_RATE(7U, 350, 3, 2), + PLL_1416X_RATE(6U, 300, 3, 2), +}; + +static const struct imx_pll14xx_rate_table imx8mm_drampll_tbl[] = { + PLL_1443X_RATE(65000U, 325, 3, 2, 0), +}; + +static struct imx_pll14xx_clk imx8mm_dram_pll __initdata = { + .type = PLL_1443X, + .rate_table = imx8mm_drampll_tbl, + .rate_count = ARRAY_SIZE(imx8mm_drampll_tbl), +}; + +static struct imx_pll14xx_clk imx8mm_arm_pll __initdata = { + .type = PLL_1416X, + .rate_table = imx8mm_pll1416x_tbl, + .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl), +}; + +static struct imx_pll14xx_clk imx8mm_sys_pll __initdata = { + .type = PLL_1416X, + .rate_table = imx8mm_pll1416x_tbl, + .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl), +}; + +static const char *pll_ref_sels[] = { "clock-osc-24m", "dummy", "dummy", "dummy", }; +static const char *dram_pll_bypass_sels[] = {"dram_pll", "dram_pll_ref_sel", }; +static const char *arm_pll_bypass_sels[] = {"arm_pll", "arm_pll_ref_sel", }; +static const char *sys_pll1_bypass_sels[] = {"sys_pll1", "sys_pll1_ref_sel", }; +static const char *sys_pll2_bypass_sels[] = {"sys_pll2", "sys_pll2_ref_sel", }; +static const char *sys_pll3_bypass_sels[] = {"sys_pll3", "sys_pll3_ref_sel", }; + +static const char *imx8mm_a53_sels[] = {"clock-osc-24m", "arm_pll_out", "sys_pll2_500m", "sys_pll2_1000m", + "sys_pll1_800m", "sys_pll1_400m", "audio_pll1_out", "sys_pll3_out", }; + +static const char *imx8mm_ahb_sels[] = {"osc_24m", "sys_pll1_133m", "sys_pll1_800m", "sys_pll1_400m", + "sys_pll2_125m", "sys_pll3_out", "audio_pll1_out", "video_pll1_out", }; + +static const char *imx8mm_enet_axi_sels[] = {"clock-osc-24m", "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_250m", +"sys_pll2_200m", "audio_pll1_out", "video_pll1_out", "sys_pll3_out", }; + +static const char *imx8mm_nand_usdhc_sels[] = {"clock-osc-24m", "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_200m", + "sys_pll1_133m", "sys_pll3_out", "sys_pll2_250m", "audio_pll1_out", }; + +static const char *imx8mm_usdhc1_sels[] = {"clock-osc-24m", "sys_pll1_400m", "sys_pll1_800m", "sys_pll2_500m", + "sys_pll3_out", "sys_pll1_266m", "audio_pll2_out", "sys_pll1_100m", }; + +static const char *imx8mm_usdhc2_sels[] = {"clock-osc-24m", "sys_pll1_400m", "sys_pll1_800m", "sys_pll2_500m", + "sys_pll3_out", "sys_pll1_266m", "audio_pll2_out", "sys_pll1_100m", }; + +static const char *imx8mm_i2c1_sels[] = {"clock-osc-24m", "sys_pll1_160m",
[U-Boot] [i.MX8MM+CCF 34/41] imx8m: soc: enable SCTR clock before timer init
To i.MX8MM SCTR clock is disabled by ROM, so before timer init need to enable it. To i.MX8MQ, it does not hurt the clock is enabled again. Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/soc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index abf526bc68..ea83a495c2 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -234,6 +234,12 @@ static void imx_set_wdog_powerdown(bool enable) int arch_cpu_init(void) { + /* +* ROM might disable clock for SCTR, +* enable the clock before timer_init. +*/ + if (IS_ENABLED(CONFIG_SPL_BUILD)) + clock_enable(CCGR_SCTR, 1); /* * Init timer at very early state, because sscg pll setting * will use it -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 23/41] imx8m: update imx-regs for i.MX8MM
i.MX8MM has similar architecture with i.MX8MQ, but it has totally different PLL design and some register layout change. Note: Some registers in this file are not updated because not used now. Signed-off-by: Peng Fan --- arch/arm/include/asm/arch-imx8m/imx-regs.h | 75 -- 1 file changed, 71 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index 3facd5450c..44b2f728ee 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -8,8 +8,8 @@ #include -#define ROM_VERSION_A0 0x800 -#define ROM_VERSION_B0 0x83C +#define ROM_VERSION_A0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x800 : 0x800 +#define ROM_VERSION_B0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x83C : 0x800 #define M4_BOOTROM_BASE_ADDR 0x007E @@ -91,7 +91,11 @@ #define SEMAPHOR_HS_BASE_ADDR 0x30AC #define USDHC1_BASE_ADDR 0x30B4 #define USDHC2_BASE_ADDR 0x30B5 +#ifdef CONFIG_IMX8MM +#define USDHC3_BASE_ADDR 0x30B6 +#else #define MIPI_CS2_BASE_ADDR 0x30B6 +#endif #define MIPI_CSI_PHY2_BASE_ADDR0x30B7 #define CSI2_BASE_ADDR 0x30B8 #define QSPI0_BASE_ADDR0x30BB @@ -118,7 +122,8 @@ #define USB1_PHY_BASE_ADDR 0x381F #define USB2_PHY_BASE_ADDR 0x382F -#define MXS_LCDIF_BASE LCDIF_BASE_ADDR +#define MXS_LCDIF_BASE is_enable(CONFIG_IMX8MQ) ? \ + 0x3032 : 0x32e0 #define SRC_IPS_BASE_ADDR 0x3039 #define SRC_DDRC_RCR_ADDR 0x30391000 @@ -147,6 +152,9 @@ #define SRC_DDR1_RCR_CORE_RESET_N_MASK BIT(1) #define SRC_DDR1_RCR_PRESET_N_MASK BIT(0) +#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK 0x2000u +#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_SHIFT 13 + struct iomuxc_gpr_base_regs { u32 gpr[47]; }; @@ -203,6 +211,7 @@ struct fuse_bank1_regs { u32 rsvd3[3]; }; +#ifdef CONFIG_IMX8MQ struct anamix_pll { u32 audio_pll1_cfg0; u32 audio_pll1_cfg1; @@ -237,6 +246,60 @@ struct anamix_pll { u32 frac_pllout_div_cfg; u32 sscg_pllout_div_cfg; }; +#else +struct anamix_pll { + u32 audio_pll1_gnrl_ctl; + u32 audio_pll1_fdiv_ctl0; + u32 audio_pll1_fdiv_ctl1; + u32 audio_pll1_sscg_ctl; + u32 audio_pll1_mnit_ctl; + u32 audio_pll2_gnrl_ctl; + u32 audio_pll2_fdiv_ctl0; + u32 audio_pll2_fdiv_ctl1; + u32 audio_pll2_sscg_ctl; + u32 audio_pll2_mnit_ctl; + u32 video_pll1_gnrl_ctl; + u32 video_pll1_fdiv_ctl0; + u32 video_pll1_fdiv_ctl1; + u32 video_pll1_sscg_ctl; + u32 video_pll1_mnit_ctl; + u32 reserved[5]; + u32 dram_pll_gnrl_ctl; + u32 dram_pll_fdiv_ctl0; + u32 dram_pll_fdiv_ctl1; + u32 dram_pll_sscg_ctl; + u32 dram_pll_mnit_ctl; + u32 gpu_pll_gnrl_ctl; + u32 gpu_pll_div_ctl; + u32 gpu_pll_locked_ctl1; + u32 gpu_pll_mnit_ctl; + u32 vpu_pll_gnrl_ctl; + u32 vpu_pll_div_ctl; + u32 vpu_pll_locked_ctl1; + u32 vpu_pll_mnit_ctl; + u32 arm_pll_gnrl_ctl; + u32 arm_pll_div_ctl; + u32 arm_pll_locked_ctl1; + u32 arm_pll_mnit_ctl; + u32 sys_pll1_gnrl_ctl; + u32 sys_pll1_div_ctl; + u32 sys_pll1_locked_ctl1; + u32 reserved2[24]; + u32 sys_pll1_mnit_ctl; + u32 sys_pll2_gnrl_ctl; + u32 sys_pll2_div_ctl; + u32 sys_pll2_locked_ctl1; + u32 sys_pll2_mnit_ctl; + u32 sys_pll3_gnrl_ctl; + u32 sys_pll3_div_ctl; + u32 sys_pll3_locked_ctl1; + u32 sys_pll3_mnit_ctl; + u32 anamix_misc_ctl; + u32 anamix_clk_mnit_ctl; + u32 reserved3[437]; + u32 digprog; +}; +#endif struct fuse_bank9_regs { u32 mac_addr0; @@ -256,11 +319,13 @@ struct src { u32 usbophy2_rcr; u32 mipiphy_rcr; u32 pciephy_rcr; + /* Exits on i.MX8MQ */ u32 hdmi_rcr; u32 disp_rcr; u32 reserved2[2]; u32 gpu_rcr; u32 vpu_rcr; + /* The following four exits on i.MX8MQ */ u32 pcie2_rcr; u32 mipiphy1_rcr; u32 mipiphy2_rcr; @@ -283,6 +348,7 @@ struct src { u32 gpr10; u32 reserved5[985]; u32 ddr1_rcr; + /* Exist on i.MX8MQ */ u32 ddr2_rcr; }; @@ -457,7 +523,8 @@ struct bootrom_sw_info { u32 reserved_3[3]; }; -#define ROM_SW_INFO_ADDR_B00x0968 +#define ROM_SW_INFO_ADDR_B0(IS_ENABLED(CONFIG_IMX8MQ) ? 0x0968 :\ +0x09e8) #define ROM_SW_INFO_ADDR_A00x09e8 #define ROM_SW_INFO_ADDR is_soc_rev(CHIP_REV_1_0) ? \ -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 27/41] imx8m: add clk support for i.MX8MM
Introduce clk implementation for i.MX8MM, including pll configuration, ccm configuration. Mostly will be done clk dm driver, but such as DRAM part, we still use non clk dm driver, because we have limited sram. Signed-off-by: Peng Fan --- arch/arm/include/asm/arch-imx8m/clock.h| 2 + arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387 + arch/arm/mach-imx/imx8m/Makefile | 1 + arch/arm/mach-imx/imx8m/clock_imx8mm.c | 292 arch/arm/mach-imx/imx8m/clock_slice.c | 461 + 5 files changed, 1143 insertions(+) create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h create mode 100644 arch/arm/mach-imx/imx8m/clock_imx8mm.c diff --git a/arch/arm/include/asm/arch-imx8m/clock.h b/arch/arm/include/asm/arch-imx8m/clock.h index 7225c760fe..ead4b8d3dc 100644 --- a/arch/arm/include/asm/arch-imx8m/clock.h +++ b/arch/arm/include/asm/arch-imx8m/clock.h @@ -7,6 +7,8 @@ #ifdef CONFIG_IMX8MQ #include +#elif defined(CONFIG_IMX8MM) +#include #else #error "Error no clock.h" #endif diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h new file mode 100644 index 00..305514a4ec --- /dev/null +++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h @@ -0,0 +1,387 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2018-2019 NXP + * + * Peng Fan + */ + +#ifndef _ASM_ARCH_IMX8MM_CLOCK_H +#define _ASM_ARCH_IMX8MM_CLOCK_H + +#define PLL_1443X_RATE(_rate, _m, _p, _s, _k) \ + { \ + .rate = (_rate),\ + .mdiv = (_m), \ + .pdiv = (_p), \ + .sdiv = (_s), \ + .kdiv = (_k), \ + } + +#define LOCK_STATUSBIT(31) +#define LOCK_SEL_MASK BIT(29) +#define CLKE_MASK BIT(11) +#define RST_MASK BIT(9) +#define BYPASS_MASKBIT(4) +#defineMDIV_SHIFT 12 +#defineMDIV_MASK GENMASK(21, 12) +#define PDIV_SHIFT 4 +#define PDIV_MASK GENMASK(9, 4) +#define SDIV_SHIFT 0 +#define SDIV_MASK GENMASK(2, 0) +#define KDIV_SHIFT 0 +#define KDIV_MASK GENMASK(15, 0) + +struct imx_int_pll_rate_table { + u32 rate; + int mdiv; + int pdiv; + int sdiv; + int kdiv; +}; + +enum pll_clocks { + ANATOP_ARM_PLL, + ANATOP_VPU_PLL, + ANATOP_GPU_PLL, + ANATOP_SYSTEM_PLL1, + ANATOP_SYSTEM_PLL2, + ANATOP_SYSTEM_PLL3, + ANATOP_AUDIO_PLL1, + ANATOP_AUDIO_PLL2, + ANATOP_VIDEO_PLL, + ANATOP_DRAM_PLL, +}; + +enum clk_root_index { + ARM_A53_CLK_ROOT= 0, + ARM_M4_CLK_ROOT = 1, + VPU_A53_CLK_ROOT= 2, + GPU3D_CLK_ROOT = 3, + GPU2D_CLK_ROOT = 4, + MAIN_AXI_CLK_ROOT = 16, + ENET_AXI_CLK_ROOT = 17, + NAND_USDHC_BUS_CLK_ROOT = 18, + VPU_BUS_CLK_ROOT= 19, + DISPLAY_AXI_CLK_ROOT= 20, + DISPLAY_APB_CLK_ROOT= 21, + DISPLAY_RTRM_CLK_ROOT = 22, + USB_BUS_CLK_ROOT= 23, + GPU_AXI_CLK_ROOT= 24, + GPU_AHB_CLK_ROOT= 25, + NOC_CLK_ROOT= 26, + NOC_APB_CLK_ROOT= 27, + AHB_CLK_ROOT= 32, + IPG_CLK_ROOT= 33, + AUDIO_AHB_CLK_ROOT = 34, + MIPI_DSI_ESC_RX_CLK_ROOT= 36, + DRAM_SEL_CFG= 48, + CORE_SEL_CFG= 49, + DRAM_ALT_CLK_ROOT = 64, + DRAM_APB_CLK_ROOT = 65, + VPU_G1_CLK_ROOT = 66, + VPU_G2_CLK_ROOT = 67, + DISPLAY_DTRC_CLK_ROOT = 68, + DISPLAY_DC8000_CLK_ROOT = 69, + PCIE_CTRL_CLK_ROOT = 70, + PCIE_PHY_CLK_ROOT = 71, + PCIE_AUX_CLK_ROOT = 72, + DC_PIXEL_CLK_ROOT = 73, + LCDIF_PIXEL_CLK_ROOT= 74, + SAI1_CLK_ROOT = 75, + SAI2_CLK_ROOT = 76, + SAI3_CLK_ROOT = 77, + SAI4_CLK_ROOT = 78, + SAI5_CLK_ROOT = 79, + SAI6_CLK_ROOT = 80, + SPDIF1_CLK_ROOT = 81, + SPDIF2_CLK_ROOT = 82, + ENET_REF_CLK_ROOT = 83, + ENET_TIMER_CLK_ROOT = 84, + ENET_PHY_REF_CLK_ROOT = 85, + NAND_CLK_ROOT = 86, + QSPI_CLK_ROOT
[U-Boot] [i.MX8MM+CCF 32/41] imx8m: set BYPASS ID SWAP to avoid AXI bus errors
set the BYPASS ID SWAP bit (GPR10 bit 1) in order for GPU not to generated AXI bus errors with TZC380 enabled. Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/soc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 5e9481c565..3918578399 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -59,6 +59,8 @@ void enable_tzc380(void) /* Enable TZASC and lock setting */ setbits_le32(>gpr[10], GPR_TZASC_EN); setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK); + if (IS_ENABLED(CONFIG_IMX8MM)) + setbits_le32(>gpr[10], BIT(1)); } void set_wdog_reset(struct wdog_regs *wdog) -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 17/41] ddr: imx8m: fix ddr firmware location when enable SPL OF
With SPL_OF_SPERATE, the device tree will be padded to end of the u-boot-spl-nodtb.bin, however we also put the ddr firmware file to this location, so need to adapt the code with SPL OF and align to 16bytes to ease copy firmware. Signed-off-by: Peng Fan --- drivers/ddr/imx/imx8m/helper.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/ddr/imx/imx8m/helper.c b/drivers/ddr/imx/imx8m/helper.c index 61cd4f6db1..1bf580d306 100644 --- a/drivers/ddr/imx/imx8m/helper.c +++ b/drivers/ddr/imx/imx8m/helper.c @@ -31,7 +31,17 @@ void ddr_load_train_firmware(enum fw_type type) unsigned long pr_to32, pr_from32; unsigned long fw_offset = type ? IMEM_2D_OFFSET : 0; unsigned long imem_start = (unsigned long)&_end + fw_offset; - unsigned long dmem_start = imem_start + IMEM_LEN; + unsigned long dmem_start; + +#ifdef CONFIG_SPL_OF_CONTROL + if (gd->fdt_blob && !fdt_check_header(gd->fdt_blob)) { + imem_start = roundup((unsigned long)&_end + +fdt_totalsize(gd->fdt_blob), 16) + + fw_offset; + } +#endif + + dmem_start = imem_start + IMEM_LEN; pr_from32 = imem_start; pr_to32 = DDR_TRAIN_CODE_BASE_ADDR + 4 * IMEM_OFFSET_ADDR; -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 29/41] imx8m: add pin header for i.MX8MM
Add pin header file for i.MX8MM To IMX8MM_PAD_NAND_WE_B_USDHC3_CLK, IOMUX_CONFIG_SION needs to be selected. Signed-off-by: Peng Fan --- arch/arm/include/asm/arch-imx8m/imx8mm_pins.h | 691 ++ 1 file changed, 691 insertions(+) create mode 100644 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h diff --git a/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h b/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h new file mode 100644 index 00..210e96e1db --- /dev/null +++ b/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h @@ -0,0 +1,691 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2018-2019 NXP + */ + +#ifndef __ASM_ARCH_IMX8MM_PINS_H__ +#define __ASM_ARCH_IMX8MM_PINS_H__ + +#include + +enum { + IMX8MM_PAD_GPIO1_IO00_GPIO1_IO0 = IOMUX_PAD(0x0290, 0x0028, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO00_CCM_ENET_PHY_REF_CLK_ROOT = IOMUX_PAD(0x0290, 0x0028, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO00_XTALOSC_REF_CLK_32K = IOMUX_PAD(0x0290, 0x0028, 5, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO00_CCM_EXT_CLK1= IOMUX_PAD(0x0290, 0x0028, 6, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO01_GPIO1_IO1 = IOMUX_PAD(0x0294, 0x002C, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO01_PWM1_OUT= IOMUX_PAD(0x0294, 0x002C, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO01_XTALOSC_REF_CLK_24M = IOMUX_PAD(0x0294, 0x002C, 5, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO01_CCM_EXT_CLK2= IOMUX_PAD(0x0294, 0x002C, 6, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO02_GPIO1_IO2 = IOMUX_PAD(0x0298, 0x0030, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_B= IOMUX_PAD(0x0298, 0x0030, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_ANY = IOMUX_PAD(0x0298, 0x0030, 5, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO03_GPIO1_IO3 = IOMUX_PAD(0x029C, 0x0034, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO03_USDHC1_VSELECT = IOMUX_PAD(0x029C, 0x0034, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO03_SDMA1_EXT_EVENT0= IOMUX_PAD(0x029C, 0x0034, 5, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO04_GPIO1_IO4 = IOMUX_PAD(0x02A0, 0x0038, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO04_USDHC2_VSELECT = IOMUX_PAD(0x02A0, 0x0038, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO04_SDMA1_EXT_EVENT1= IOMUX_PAD(0x02A0, 0x0038, 5, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO05_GPIO1_IO5 = IOMUX_PAD(0x02A4, 0x003C, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO05_ARM_PLATFORM_M4_NMI = IOMUX_PAD(0x02A4, 0x003C, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO05_CCM_PMIC_READY = IOMUX_PAD(0x02A4, 0x003C, 5, 0x04BC, 0, 0), + IMX8MM_PAD_GPIO1_IO05_SRC_INT_BOOT= IOMUX_PAD(0x02A4, 0x003C, 6, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO06_GPIO1_IO6 = IOMUX_PAD(0x02A8, 0x0040, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO06_ENET1_MDC = IOMUX_PAD(0x02A8, 0x0040, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO06_USDHC1_CD_B = IOMUX_PAD(0x02A8, 0x0040, 5, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO06_CCM_EXT_CLK3= IOMUX_PAD(0x02A8, 0x0040, 6, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO07_GPIO1_IO7 = IOMUX_PAD(0x02AC, 0x0044, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO07_ENET1_MDIO = IOMUX_PAD(0x02AC, 0x0044, 1, 0x04C0, 0, 0), + IMX8MM_PAD_GPIO1_IO07_USDHC1_WP = IOMUX_PAD(0x02AC, 0x0044, 5, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO07_CCM_EXT_CLK4= IOMUX_PAD(0x02AC, 0x0044, 6, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO08_GPIO1_IO8 = IOMUX_PAD(0x02B0, 0x0048, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO08_ENET1_1588_EVENT0_IN= IOMUX_PAD(0x02B0, 0x0048, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO08_USDHC2_RESET_B = IOMUX_PAD(0x02B0, 0x0048, 5, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO08_CCM_WAIT= IOMUX_PAD(0x02B0, 0x0048, 6, 0x, 0, 0), + + IMX8MM_PAD_GPIO1_IO09_GPIO1_IO9 = IOMUX_PAD(0x02B4, 0x004C, 0, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO09_ENET1_1588_EVENT0_OUT = IOMUX_PAD(0x02B4, 0x004C, 1, 0x, 0, 0), + IMX8MM_PAD_GPIO1_IO09_USDHC3_RESET_B = IOMUX_PAD(0x02B4, 0x004C, 4, 0x,
[U-Boot] [i.MX8MM+CCF 33/41] imx8m: Configure trustzone region 0 for non-secure access
From: Ye Li Set trustzone region 0 to allow both non-secure and secure access when trust zone is enabled. We found USB controller fails to access DDR if the default region 0 is secure access only. Signed-off-by: Ye Li Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/soc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 3918578399..abf526bc68 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -61,6 +61,12 @@ void enable_tzc380(void) setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK); if (IS_ENABLED(CONFIG_IMX8MM)) setbits_le32(>gpr[10], BIT(1)); + /* +* set Region 0 attribute to allow secure and non-secure +* read/write permission. Found some masters like usb dwc3 +* controllers can't work with secure memory. +*/ + writel(0xf000, TZASC_BASE_ADDR + 0x108); } void set_wdog_reset(struct wdog_regs *wdog) -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 16/41] drivers: core: use strcmp when find device by name
`if (!strncmp(dev->name, name, strlen(name)))` might find out the wrong device, it might find out `dram_pll_ref_sel`, when name is `dram_pll`. So use strcmp to avoid such issue. Signed-off-by: Peng Fan --- drivers/core/uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c index fc3157de39..e2f35393a9 100644 --- a/drivers/core/uclass.c +++ b/drivers/core/uclass.c @@ -260,7 +260,7 @@ int uclass_find_device_by_name(enum uclass_id id, const char *name, return ret; uclass_foreach_dev(dev, uc) { - if (!strncmp(dev->name, name, strlen(name))) { + if (!strcmp(dev->name, name)) { *devp = dev; return 0; } -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [i.MX8MM+CCF 37/41] clk: imx: add pll14xx driver
Add pll14xx driver Signed-off-by: Peng Fan --- drivers/clk/imx/clk-pll14xx.c | 377 ++ drivers/clk/imx/clk.h | 25 +++ 2 files changed, 402 insertions(+) create mode 100644 drivers/clk/imx/clk-pll14xx.c diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c new file mode 100644 index 00..a398b0bbc4 --- /dev/null +++ b/drivers/clk/imx/clk-pll14xx.c @@ -0,0 +1,377 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright 2017-2019 NXP. + * + * Peng Fan + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "clk.h" + +#define UBOOT_DM_CLK_IMX_PLL1443X "imx_clk_pll1443x" +#define UBOOT_DM_CLK_IMX_PLL1416X "imx_clk_pll1416x" + +#define GNRL_CTL 0x0 +#define DIV_CTL0x4 +#define LOCK_STATUSBIT(31) +#define LOCK_SEL_MASK BIT(29) +#define CLKE_MASK BIT(11) +#define RST_MASK BIT(9) +#define BYPASS_MASKBIT(4) +#define MDIV_SHIFT 12 +#define MDIV_MASK GENMASK(21, 12) +#define PDIV_SHIFT 4 +#define PDIV_MASK GENMASK(9, 4) +#define SDIV_SHIFT 0 +#define SDIV_MASK GENMASK(2, 0) +#define KDIV_SHIFT 0 +#define KDIV_MASK GENMASK(15, 0) + +#define LOCK_TIMEOUT_US1 + +struct clk_pll14xx { + struct clk clk; + void __iomem*base; + enum imx_pll14xx_type type; + const struct imx_pll14xx_rate_table *rate_table; + int rate_count; +}; + +#define to_clk_pll14xx(_clk) container_of(_clk, struct clk_pll14xx, clk) + +static const struct imx_pll14xx_rate_table *imx_get_pll_settings( + struct clk_pll14xx *pll, unsigned long rate) +{ + const struct imx_pll14xx_rate_table *rate_table = pll->rate_table; + int i; + + for (i = 0; i < pll->rate_count; i++) + if (rate == rate_table[i].rate) + return _table[i]; + + return NULL; +} + +static unsigned long clk_pll1416x_recalc_rate(struct clk *clk) +{ + struct clk_pll14xx *pll = to_clk_pll14xx( + (struct clk *)dev_get_driver_data(clk->dev)); + u32 mdiv, pdiv, sdiv, pll_div; + u64 fvco = clk_get_parent_rate(clk); + + pll_div = readl(pll->base + 4); + mdiv = (pll_div & MDIV_MASK) >> MDIV_SHIFT; + pdiv = (pll_div & PDIV_MASK) >> PDIV_SHIFT; + sdiv = (pll_div & SDIV_MASK) >> SDIV_SHIFT; + + fvco *= mdiv; + do_div(fvco, pdiv << sdiv); + + return fvco; +} + +static unsigned long clk_pll1443x_recalc_rate(struct clk *clk) +{ + struct clk_pll14xx *pll = to_clk_pll14xx( + (struct clk *)dev_get_driver_data(clk->dev)); + u32 mdiv, pdiv, sdiv, pll_div_ctl0, pll_div_ctl1; + short int kdiv; + u64 fvco = clk_get_parent_rate(clk); + + pll_div_ctl0 = readl(pll->base + 4); + pll_div_ctl1 = readl(pll->base + 8); + mdiv = (pll_div_ctl0 & MDIV_MASK) >> MDIV_SHIFT; + pdiv = (pll_div_ctl0 & PDIV_MASK) >> PDIV_SHIFT; + sdiv = (pll_div_ctl0 & SDIV_MASK) >> SDIV_SHIFT; + kdiv = pll_div_ctl1 & KDIV_MASK; + + /* fvco = (m * 65536 + k) * Fin / (p * 65536) */ + fvco *= (mdiv * 65536 + kdiv); + pdiv *= 65536; + + do_div(fvco, pdiv << sdiv); + + return fvco; +} + +static inline bool clk_pll1416x_mp_change(const struct imx_pll14xx_rate_table *rate, + u32 pll_div) +{ + u32 old_mdiv, old_pdiv; + + old_mdiv = (pll_div >> MDIV_SHIFT) & MDIV_MASK; + old_pdiv = (pll_div >> PDIV_SHIFT) & PDIV_MASK; + + return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv; +} + +static inline bool clk_pll1443x_mpk_change(const struct imx_pll14xx_rate_table *rate, + u32 pll_div_ctl0, u32 pll_div_ctl1) +{ + u32 old_mdiv, old_pdiv, old_kdiv; + + old_mdiv = (pll_div_ctl0 >> MDIV_SHIFT) & MDIV_MASK; + old_pdiv = (pll_div_ctl0 >> PDIV_SHIFT) & PDIV_MASK; + old_kdiv = (pll_div_ctl1 >> KDIV_SHIFT) & KDIV_MASK; + + return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv || + rate->kdiv != old_kdiv; +} + +static inline bool clk_pll1443x_mp_change(const struct imx_pll14xx_rate_table *rate, + u32 pll_div_ctl0, u32 pll_div_ctl1) +{ + u32 old_mdiv, old_pdiv, old_kdiv; + + old_mdiv = (pll_div_ctl0 >> MDIV_SHIFT) & MDIV_MASK; + old_pdiv = (pll_div_ctl0 >> PDIV_SHIFT) & PDIV_MASK; + old_kdiv = (pll_div_ctl1 >> KDIV_SHIFT) & KDIV_MASK; + + return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv || + rate->kdiv != old_kdiv; +} + +static int clk_pll14xx_wait_lock(struct clk_pll14xx *pll) +{ + u32 val; + + return readl_poll_timeout(pll->base, val, val & LOCK_TIMEOUT_US, + LOCK_TIMEOUT_US); +} + +static ulong clk_pll1416x_set_rate(struct clk
[U-Boot] [i.MX8MM+CCF 36/41] clk: imx: add Kconfig entry for i.MX8MM
Add Kconfig entry for i.MX8MM, select CLK_CCF and SPL_CLK_CCF Signed-off-by: Peng Fan --- drivers/clk/imx/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index 469768b5c3..0e4c68659c 100644 --- a/drivers/clk/imx/Kconfig +++ b/drivers/clk/imx/Kconfig @@ -13,3 +13,12 @@ config CLK_IMX8 select CLK help This enables support clock driver for i.MX8 platforms. + +config CLK_IMX8MM + bool "Clock support for i.MX8MM" + depends on IMX8MM + select CLK + select CLK_CCF + select SPL_CLK_CCF + help + This enables support clock driver for i.MX8 platforms. -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot