Re: [U-Boot] [PATCH 3/3] rockchip: correct ARCH_SOC name
> On 28.03.2019, at 04:01, Kever Yang wrote: > > The ARCH_SOC name default as 'rockchip' and we put all the > header file in 'arch/arm/include/asm/arch-rockchip/', but > the 'rockchip' is not the SOC name, let's correct it after > we update all the source file. > > Signed-off-by: Kever Yang Reviewed-by: Philipp Tomsiich Just a style question: most of the documentation refers to the chips as RK3… while this has them as rk3… (i.e. the differenc eis whether the RK is lower- or upper-case); is this difference intentional? Thanks, Phil. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] rockchip: arm: use 'arch-rockchip' for common header
> On 28.03.2019, at 04:01, Kever Yang wrote: > > rockchip platform header file is in 'arch-rockchip' > instead of arch-$(SOC) for all SoCs. > > Signed-off-by: Kever Yang Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: arm: remove no use macro
Kever, > On 28.03.2019, at 02:17, Kever Yang wrote: You are missing a commit message on this one. Please revise and resubmit, thanks. These cleanups are much appreciated, though. > Signed-off-by: Kever Yang > --- > > arch/arm/include/asm/arch-rockchip/hardware.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/include/asm/arch-rockchip/hardware.h > b/arch/arm/include/asm/arch-rockchip/hardware.h > index cd94bdd1ba..62e8bed8f3 100644 > --- a/arch/arm/include/asm/arch-rockchip/hardware.h > +++ b/arch/arm/include/asm/arch-rockchip/hardware.h > @@ -10,8 +10,6 @@ > #define RK_SETBITS(set) RK_CLRSETBITS(0, set) > #define RK_CLRBITS(clr) RK_CLRSETBITS(clr, 0) > > -#define TIMER7_BASE 0xff810020 > - > #define rk_clrsetreg(addr, clr, set) \ > writel(((clr) | (set)) << 16 | (set), addr) > #define rk_clrreg(addr, clr) writel((clr) << 16, addr) > -- > 2.20.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: define development target in README.uefi
Describe the target scope of the UEFI implementation in U-Boot. Signed-off-by: Heinrich Schuchardt --- doc/README.uefi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/README.uefi b/doc/README.uefi index b38efbc0cc..66b6abece5 100644 --- a/doc/README.uefi +++ b/doc/README.uefi @@ -12,6 +12,15 @@ the interaction of drivers and applications with the firmware. The API comprises access to block storage, network, and console to name a few. The Linux kernel and boot loaders like GRUB or the FreeBSD loader can be executed. +## Development target + +The implementation of UEFI in U-Boot strives to reach the minimum requirements +described in "Server Base Boot Requirements System Software on ARM Platforms - +Version 1.1" [4]. + +A full blown UEFI implementation would contradict the U-Boot design principle +"keep it small". + ## Building for UEFI The UEFI standard supports only little-endian systems. The UEFI support can be @@ -335,3 +344,5 @@ This driver is only available if U-Boot is configured with http://uefi.org/specifications - UEFI specifications * [2](./driver-model/README.txt) doc/driver-model/README.txt - Driver model * [3](./README.iscsi) doc/README.iscsi - iSCSI booting with U-Boot and iPXE +* [4](https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-system-software-on-arm-platforms-version-11) + Server Base Boot Requirements System Software on ARM Platforms - Version 1.1 -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: at91: sama5d2: Wrap cpu detection to fix macb driver
On 22.03.2019 15:25, Alexander Dahl wrote: > When introducing the SAMA5D27 SoCs, the SAMA5D2 series got an additional > chip id. The check if the cpu is sama5d2 was changed from a preprocessor > definition (inlining a call to 'get_chip_id()') to a C function, > probably to not call get_chip_id twice? > > That however broke a check in the macb ethernet driver. That driver is > more generic and also used for other platforms. I suppose this solution > was implemented to use it in 'gem_is_gigabit_capable()', without having > to stricly depend on the at91 platform: > > #ifndef cpu_is_sama5d2 > #define cpu_is_sama5d2() 0 > #endif > > That only works as long as cpu_is_sama5d2 is a preprocessor definition. > (The same is still true for sama5d4 by the way.) So this is a straight > forward fix for the workaround. > > The not working check on the SAMA5D2 CPU lead to an issue on a custom > board with a LAN8720A ethernet phy connected to the SoC: > > => dhcp > ethernet@f8008000: PHY present at 1 > ethernet@f8008000: Starting autonegotiation... > ethernet@f8008000: Autonegotiation complete > ethernet@f8008000: link up, 1000Mbps full-duplex (lpa: 0x) > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > BOOTP broadcast 5 > BOOTP broadcast 6 > BOOTP broadcast 7 > BOOTP broadcast 8 > BOOTP broadcast 9 > BOOTP broadcast 10 > BOOTP broadcast 11 > BOOTP broadcast 12 > BOOTP broadcast 13 > BOOTP broadcast 14 > BOOTP broadcast 15 > BOOTP broadcast 16 > BOOTP broadcast 17 > > Retry time exceeded; starting again > > Notice the wrong reported link speed, although both SoC and phy only > support 100 MBit/s! > > The real issue on reliably detecting the features of that cadence > ethernet mac IP block, is probably more complicated, though. > > Fixes: 245cbc583db7c1ca52aa32428b8e86f3449d4af2 > Signed-off-by: Alexander Dahl > --- Applied to u-boot-atmel/next , with a minor tweak on fixes tag Thanks ! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: video: HDMI: Fix clock setup
On Sun, Mar 24, 2019 at 11:56 PM Jernej Skrabec wrote:
>
> Currently, HDMI driver doesn't consider minimum and maximum allowed rate
> of pll3 (video PLL). It works most of the time, but not always.
>
> Consider monitor with resolution 1920x1200, which has pixel clock rate
> of 154 MHz. Current code would determine that pll3 rate has to be set to
> 154 MHz. However, minimum supported rate is 192 MHz. In this case video
> output just won't work.
I set the monitor with same resolution, but not sure with the pixel
clock and unable to reproduce this with couple time. any specific
usage case that the issue will reproduce ?
>
> The reason why the driver is written in the way it is, is that at the
> time HDMI PHY and clock configuration wasn't fully understood. But now
> we have needed knowledge, so the issue can be fixed.
>
> With this fix, clock configuration routine uses full range (1-16) for
> clock divider instead of limited one (1, 2, 4, 11). It also considers
> minimum and maximum allowed rate for pll3.
>
> Fixes: 56009451d843 ("sunxi: video: Add A64/H3/H5 HDMI driver")
> Signed-off-by: Jernej Skrabec
> ---
> Hi!
>
> Unfortunately, issue fixed with patch here has influence on Linux too.
> In Linux, minimum and maximum rate is considered only when changing rate.
> But because U-Boot already set PLL to "correct" value, Linux clock driver
> doesn't see the need to change it. I know that this is Linux driver issue
> but let's start at the source of the issue and fix it.
>
> It would be very nice if this can go in 2019.04 release.
>
> Best regards,
> Jernej
>
> drivers/video/sunxi/sunxi_dw_hdmi.c | 62 +
> 1 file changed, 37 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
> b/drivers/video/sunxi/sunxi_dw_hdmi.c
> index 9dbea649a0..6fe1aa7ee4 100644
> --- a/drivers/video/sunxi/sunxi_dw_hdmi.c
> +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
> @@ -132,7 +132,7 @@ static int sunxi_dw_hdmi_wait_for_hpd(void)
> return -1;
> }
>
> -static void sunxi_dw_hdmi_phy_set(uint clock)
> +static void sunxi_dw_hdmi_phy_set(uint clock, int phy_div)
> {
> struct sunxi_hdmi_phy * const phy =
> (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE + HDMI_PHY_OFFS);
> @@ -146,7 +146,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> switch (div) {
> case 1:
> writel(0x30dc5fc0, &phy->pll);
> - writel(0x800863C0, &phy->clk);
> + writel(0x800863C0 | (phy_div - 1), &phy->clk);
> mdelay(10);
> writel(0x0001, &phy->unk3);
> setbits_le32(&phy->pll, BIT(25));
> @@ -164,7 +164,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> break;
> case 2:
> writel(0x39dc5040, &phy->pll);
> - writel(0x80084381, &phy->clk);
> + writel(0x80084380 | (phy_div - 1), &phy->clk);
> mdelay(10);
> writel(0x0001, &phy->unk3);
> setbits_le32(&phy->pll, BIT(25));
> @@ -178,7 +178,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> break;
> case 4:
> writel(0x39dc5040, &phy->pll);
> - writel(0x80084343, &phy->clk);
> + writel(0x80084340 | (phy_div - 1), &phy->clk);
> mdelay(10);
> writel(0x0001, &phy->unk3);
> setbits_le32(&phy->pll, BIT(25));
> @@ -192,7 +192,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> break;
> case 11:
> writel(0x39dc5040, &phy->pll);
> - writel(0x8008430a, &phy->clk);
> + writel(0x80084300 | (phy_div - 1), &phy->clk);
> mdelay(10);
> writel(0x0001, &phy->unk3);
> setbits_le32(&phy->pll, BIT(25));
> @@ -207,36 +207,46 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> }
> }
>
> -static void sunxi_dw_hdmi_pll_set(uint clk_khz)
> +static void sunxi_dw_hdmi_pll_set(uint clk_khz, int *phy_div)
> {
> - int value, n, m, div = 0, diff;
> - int best_n = 0, best_m = 0, best_diff = 0x0FFF;
> -
> - div = sunxi_dw_hdmi_get_divider(clk_khz * 1000);
> + int value, n, m, div, diff;
> + int best_n = 0, best_m = 0, best_div = 0, best_diff = 0x0FFF;
>
> /*
> * Find the lowest divider resulting in a matching clock. If there
> * is no match, pick the closest lower clock, as monitors tend to
> * not sync to higher frequencies.
> */
> - for (m = 1; m <= 16; m++) {
> - n = (m * div * clk_khz) / 24000;
> -
> - if ((n >= 1) && (n <= 128)) {
> - value = (24000 * n) / m / div;
> - diff = clk_khz - value;
> - if (diff < best_diff) {
> - best_diff = diff;
> - best_m
[U-Boot] Please pull ARC last minute changes for 2019.04
Hi Tom, The following changes since commit 2b9b9cdd5f9ae1cbc786ba3c2255a51b3ea4a636: Merge branch '2019-03-25-master-imports' (2019-03-26 23:17:21 -0400) are available in the Git repository at: git://git.denx.de/u-boot-arc.git tags/arc-last-minute-for-2019.04 for you to fetch changes up to 34d117b1fb055920e742baafdd9c1a390c480519: hsdk: readme: Suggest getting pyelftools with pip (2019-03-28 10:50:32 +0300) This is last minute change which fixes problems in runtime on AXS10x board caused by some changes in NAND framework and tiny documentation improvement. Anyways NAND flash storage was never really used on the board for various reasons and now we decided to drop it for good. Note this change only touches 1 ARC board so that should be safe for others. As usual - build tested in TravisCI, see https://travis-ci.org/abrodkin/u-boot/builds/512041342 Alexey Brodkin (1): hsdk: readme: Suggest getting pyelftools with pip Eugeniy Paltsev (1): ARC: AXS10x: drop NAND support board/synopsys/axs10x/Makefile | 1 - board/synopsys/axs10x/nand.c | 242 -- board/synopsys/hsdk/README | 7 ++-- configs/axs101_defconfig | 1 - configs/axs103_defconfig | 1 - include/configs/axs10x.h | 6 --- 6 files changed, 4 insertions(+), 254 deletions(-) delete mode 100644 board/synopsys/axs10x/nand.c -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,V4,1/2] mmc: add HS400 support
> -Original Message-
> From: Trent Piepho [mailto:tpie...@impinj.com]
> Sent: 2019年3月28日 4:43
> To: Peng Fan ; jh80.ch...@samsung.com;
> sba...@denx.de
> Cc: ma...@denx.de; kis...@ti.com; dl-linux-imx ;
> u-boot@lists.denx.de
> Subject: Re: [U-Boot,V4,1/2] mmc: add HS400 support
>
> I didn't see HS400 working on my IMX7d, even thought it appears it should be
> supported.
>
> The problem appears to be when this bit of code in fsl_esdhc.c, which dates to
> a patch "mmc: fsl_esdhc: support SDR104 and HS200":
>
> static struct esdhc_soc_data usdhc_imx7d_data = {
> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> | ESDHC_FLAG_HAVE_CAP1 |
> ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400,
> .caps = UHS_CAPS | MMC_MODE_HS200 |
> MMC_MODE_DDR_52MHz |
> MMC_MODE_HS_52MHz | MMC_MODE_HS, };
>
> Notice that MMC_MODE_HS400 isn't in the caps list. Once I add that uboot
> will attempt HS400 and it appears to work correctly.
>
> I think maybe this patch should have added this to the caps?
>
> Alternatively, there is a property that can be added to the device tree,
> mmc-hs400-1_8v, that will add this cap. But the code to parse those dt
> properties, mmc_of_parse(), isn't used by the fsl_esdhc driver, which has its
> own parsing code that doesn't know about mmc- hs400-1_8v.
>
> So maybe fsl-esdhc should use mmc_of_parse() and the appropriate iMX DTs
> should add those properties?
>
> I think the DT method might be better, since it would allow the DT to not
> list a
> mode that doesn't work due to the the board. I.e., the iMX host supports
> the mode, the eMMC supports the mode, but the board layout doesn't have
> traces that can support it. Too long, not matched well enough, etc. It
> doesn't seem like there's an nice way to remove a mode otherwise.
Yes. Parse device tree will be better.
Regards,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS
> -Original Message- > From: Yinbo Zhu > Sent: 2019年3月26日 17:08 > To: York Sun ; u-boot@lists.denx.de > Cc: Xiaobo Xie ; Ran Wang ; Jiafei > Pan ; Y.b. Lu ; Jagdish Gediya > ; Prabhakar Kushwaha > ; 'Yinbo Zhu' > Subject: RE: [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS > > Hi, > > This patches set is for enable uboot DM for usb and sd on t2080qds, I haded > tested the io function. And I find that if the block size is less than 8, the > read > process will be hung, hung’s code is in blkcache_fill’s memcpy Function, and > when memcpy do “*dl++ = *sl++” operation then read process will be hung. > but fsl-layerscape uboot DM work well. ppc non-DM work well, it seems to be > block driver(CONFIG_BLK) issue related to PPC. Please you note. > > Thanks > Best Regards, > Yinbo Zhu. > Hi York, Could you help me check these patches! Thanks In addition, above issue is due to the mmc read's operation address is out of memory address, not a bug. Please you note! > -Original Message- > From: Yinbo Zhu [mailto:yinbo@nxp.com] > Sent: 2019年3月26日 11:09 > To: York Sun ; u-boot@lists.denx.de > Cc: Yinbo Zhu ; Xiaobo Xie ; Ran > Wang ; Jiafei Pan ; Y.b. Lu > ; Jagdish Gediya ; Prabhakar > Kushwaha > Subject: [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS > > >From: Yinbo Zhu > > >This patch is to enable MMC DM for T2080QDS in uboot > > >Signed-off-by: Yinbo Zhu > >--- > >configs/T2080QDS_NAND_defconfig | 3 +++ > >configs/T2080QDS_SDCARD_defconfig | 3 +++ > >configs/T2080QDS_SECURE_BOOT_defconfig| 3 +++ > >configs/T2080QDS_SPIFLASH_defconfig | 3 +++ > >configs/T2080QDS_SRIO_PCIE_BOOT_defconfig | 3 +++ > >configs/T2080QDS_defconfig| 3 +++ > >6 files changed, 18 insertions(+) > > >diff --git a/configs/T2080QDS_NAND_defconfig > >b/configs/T2080QDS_NAND_defconfig index 948a05af89..02d47c9fdd > 100644 > >--- a/configs/T2080QDS_NAND_defconfig > >+++ b/configs/T2080QDS_NAND_defconfig > >@@ -59,3 +59,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_SDCARD_defconfig > >b/configs/T2080QDS_SDCARD_defconfig > >index 30e87df3bb..4ce83fe8c4 100644 > >--- a/configs/T2080QDS_SDCARD_defconfig > >+++ b/configs/T2080QDS_SDCARD_defconfig > >@@ -58,3 +58,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_SECURE_BOOT_defconfig > >b/configs/T2080QDS_SECURE_BOOT_defconfig > >index 2658bf8460..e2a7d3fa76 100644 > >--- a/configs/T2080QDS_SECURE_BOOT_defconfig > >+++ b/configs/T2080QDS_SECURE_BOOT_defconfig > >@@ -52,3 +52,6 @@ CONFIG_RSA_SOFTWARE_EXP=y CONFIG_OF_LIBFDT=y > >CONFIG_MPC85XX_HAVE_RESET_VECTOR=y > >CONFIG_DEFAULT_DEVICE_TREE="t2080qds" > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_OF_CONTROL=y > >diff --git a/configs/T2080QDS_SPIFLASH_defconfig > >b/configs/T2080QDS_SPIFLASH_defconfig > >index 0cccb3a85d..641f3c0c97 100644 > >--- a/configs/T2080QDS_SPIFLASH_defconfig > >+++ b/configs/T2080QDS_SPIFLASH_defconfig > >@@ -59,3 +59,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >b/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >index 8febabd84f..d2a8875aac 100644 > >--- a/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >+++ b/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >@@ -42,3 +42,6 @@ CONFIG_OF_LIBFDT=y > >CONFIG_MPC85XX_HAVE_RESET_VECTOR=y > >CONFIG_OF_CONTROL=y > >CONFIG_DEFAULT_DEVICE_TREE="t2080qds" > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_defconfig b/configs/T2080QDS_defconfig > >index 79cf4424b4..d55ce771a9 100644 > >--- a/configs/T2080QDS_defconfig > >+++ b/configs/T2080QDS_defconfig > >@@ -48,3 +48,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >>CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > -- > 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: update TODOs in doc/README.uefi
On Thu, Mar 28, 2019 at 07:52:53AM +0100, Heinrich Schuchardt wrote: > On 3/28/19 1:50 AM, AKASHI Takahiro wrote: > > Hi Heinrich, > > > > As a matter of fact and strictly speaking, there are bunch of > > missing features; > > * Boot manager (section 3) > > - boot manager policy > > - support for some of Boot option variables > > - boot recovery > > * various protocols, > > - from section 11 to section 20 and > > - from section 24 to section 30 > > * Firmware Update (Spec section 23) > > * UEFI Byte Code(EBC) machine (Spec section 22) > > * Secure boot (Spec section 31) > > * Support for some of HII packages (section 33) > > * HII configuration protocols (section 34) > > * security&crypto-related protocols (section 36) > > * Variables > > - support for authentication > > > > I don't think that we should list all of them, but we should definitely > > describe the *criteria* for what features be implemented and what not. > > Alex suggested to base the scope of our implementation on the minimum > requirements of this document: Yeah, I heard that but "minimum" is always a moving target and > Server Base Boot Requirements System Software on ARM Platforms - Version 1.1 > https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-system-software-on-arm-platforms-version-11 this document yet has a much larger amount of requirements list than current U-Boot supports. -Takahiro Akashi > > > > # Personally, I'd like to add "integration of DM and UEFI objects" :) > > The deficiencies that I listed in README.uefi are the user view. > > I agree that we should also define our U-Boot internal development > targets and better DM-UEFI integration should be part of it. > > Best regards > > Heinrich > > > > > Thanks, > > -Takahiro Akashi > > > > On Wed, Mar 27, 2019 at 10:07:03PM +0100, Heinrich Schuchardt wrote: > >> The following TODOs are closed: > >> > >> - GetNextVariableName is not implemented > >> - event groups > >> - manage events in a linked list > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> doc/README.uefi | 5 + > >> 1 file changed, 1 insertion(+), 4 deletions(-) > >> > >> diff --git a/doc/README.uefi b/doc/README.uefi > >> index cda29cdcf7..b38efbc0cc 100644 > >> --- a/doc/README.uefi > >> +++ b/doc/README.uefi > >> @@ -299,7 +299,7 @@ This driver is only available if U-Boot is configured > >> with > >> CONFIG_BLK=y > >> CONFIG_PARTITIONS=y > >> > >> -## TODOs as of U-Boot 2018.07 > >> +## TODOs as of U-Boot 2019.04 > >> > >> * unimplemented or incompletely implemented boot services > >>* Exit - call unload function, unload applications only > >> @@ -308,16 +308,13 @@ This driver is only available if U-Boot is > >> configured with > >> > >> * unimplemented or incompletely implemented runtime services > >>* SetVariable() ignores attribute EFI_VARIABLE_APPEND_WRITE > >> - * GetNextVariableName is not implemented > >>* QueryVariableInfo is not implemented > >> > >> * unimplemented events > >>* EVT_RUNTIME > >>* EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE > >> - * event groups > >> > >> * data model > >> - * manage events in a linked list > >>* manage configuration tables in a linked list > >> > >> * UEFI drivers > >> -- > >> 2.20.1 > >> > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.04-rc3 released
On Thu, Mar 28, 2019 at 12:10 AM Peter Robinson wrote: > > > > Hi Jagan, > > > > > > Did you get a chance to test this? We've seen this on at least Cubie2, > > > CubieTruck and BananaPi and it still persists with rc4 > > > > I made a quick test on v2019.01 vs v2019.04-rc3, below are the > > results. I even grab the reg dump for your information. please check > > the same. > > So further testing on this from the people seeing the problem shows > it's an issue when booting the OS off a SATA/AHCI attached device. So > a mSD card with U-Boot on it and the rest of the OS on a SSD or > similar, booting the OS off mSD works as expected. Is sd issue still persist? > > Output: > > U-Boot SPL 2019.04-rc4 (Mar 20 2019 - 15:48:13 +) > DRAM: 2048 MiB > CPU: 91200Hz, AXI/AHB/APB: 3/2/2 > Trying to boot from MMC1 > > > U-Boot 2019.04-rc4 (Mar 20 2019 - 15:48:13 +) Allwinner Technology > > CPU: Allwinner A20 (SUN7I) > Model: Cubietech Cubietruck > I2C: ready > DRAM: 2 GiB > MMC: mmc@1c0f000: 0, mmc@1c12000: 1 > Loading Environment from FAT... Unable to use mmc 0:2... Setting up a > 1024x768 vga console (overscan 0x0) > In:serial > Out: vga > Err: vga > Allwinner mUSB OTG (Peripheral) > SCSI: Target spinup took 0 ms. > AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode > flags: ncq stag pm led clo only pmp pio slum part ccc apst > > Net: sunxi_set_gate: (CLK#66) unhandled > eth0: ethernet@1c5 > Warning: usb_ether using MAC address from ROM > , eth1: usb_ether > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > USB2: USB EHCI 1.00 > USB3: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 1 for devices... 1 USB Device(s) found > scanning bus 2 for devices... 1 USB Device(s) found > scanning bus 3 for devices... 1 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > => scsi info > => scsi reset > > Reset SCSI > scanning bus for devices... > data abort > pc : [] lr : [] > reloc pc : [<4a01c82a>]lr : [<4a017e51>] > sp : baf46b58 ip : 001c fp : 00c0 > r10: r9 : baf4eed8 r8 : > r7 : baf46dd8 r6 : befd4094 r5 : befdbd30 r4 : befdbd30 > r3 : r2 : r1 : ea16 r0 : befdbd30 > Flags: nZcv IRQs off FIQs off Mode SVC_32 > Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604) > Resetting CPU ... Have you reproduce the same in previous release? better bisect it. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/36] rockchip: add STIMER_BASE for all SoCs
Hi U-Boot Maintainers: I would like to close this topic and update all related source code, you can find the previous discussion at [0][1]. Philipp object this patch and his original reason is: > This should not be in Kconfig and rather in a header-file. > With what you do here, a user (e.g. via 'make menuconfig') or a defconfig > file (e.g. due to a typo) could accidentially change overwrite this. and Philipp also think: > asm/arch-rockchip would be preferable over include/config as a header There are many ways for feature configure on rockchip platform now: - board dts; - header file in include/config - Kconfig in $(BOARD)_defconfig - Kconfig default value in 'Kconfig' file Already too many place to config, we should make it simple rather than complex. I think people are migrating more and more configurations from header file to Kconfig, including: - option for enable/disable modules; - option for module parameter which is numerical value; - option for module parameter which is string; I think the target is that most of the configs goes to Kconfig and user can config options with menuconfig and no need to touch header file(Please tell me if this is not true). And for all those config options, I think at lease can be separate into two kind: - options per-board; - options per-soc (some of them may per-vendor); I think the idealized model would be per-soc options goes to 'Kconfig' file with default value combine with SOC, and per-board options at $(BOARD)_defconfig. ROCKCHIP_STIMER_REG(another case is BOOT_MODE_REG) is per-soc config option, just like SYS_TEXT_BASE, TPL_TEXT_BASE, TPL_MAX_SIZE, SYS_SOC and so on. Driver for different SOCs to use this reg are just the same, and this reg needs to be used very early in TPL/SPL which means no DM, no dts available. Here are the solutions from previous discussion: - dts (by Simon) extra dtb code needed, setting separate into individual board dts; not available and not suggestion to use in TPL/SPL; - move to header in 'asm/arch-rockchip' (by Philipp) one more place to config, make config options more complicate; may separate in more than 10+ files for different soc/board; - RMII setting like, (by Philipp) reference to 'drivers/net/gmac_rockchip.c', driver for different SoCs are not re-usable, driver needs to update for each new SoC support; not available with DM in early TPL/SPL; - Kconfig with default value in this patch Keep driver clean and no need to update with new SoC; One place rather than 10+ individual files, same usage like SYS_TEXT_BASE, reference to: 341c058654 sunxi: move CONFIG_SYS_TEXT_BASE out of defconfigs I think the default value in Kconfig is the best solution, the SPL/TPL should be small, fast and with enough functionality for use. Thanks, - Kever [0] https://patchwork.ozlabs.org/patch/1004148/ [1] http://patchwork.ozlabs.org/patch/891462/ Kever Yang 于2018年3月27日周二 下午5:30写道： > STIMER is can only access in secure mode if the SoCs supports trust, > and it locate in alive power domain, as the source of ARM arch/generic > timer, we add a base addr for all SoCs so that we can init with a common > function. > > Signed-off-by: Kever Yang > --- > > arch/arm/mach-rockchip/Kconfig | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/arch/arm/mach-rockchip/Kconfig > b/arch/arm/mach-rockchip/Kconfig > index 007cb22..5dfe452 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -190,6 +190,25 @@ config ROCKCHIP_BOOT_MODE_REG > The Soc will enter to different boot mode(defined in > asm/arch/boot_mode.h) > according to the value from this register. > > +config ROCKCHIP_STIMER_BASE > + hex "Rockchip Secure timer base address" > + default 0xff220020 if ROCKCHIP_PX30 > + default 0x200440a0 if ROCKCHIP_RK3036 > + default 0x2000e000 if ROCKCHIP_RK3066 > + default 0x20018020 if ROCKCHIP_RK3126 > + default 0x200440a0 if ROCKCHIP_RK3128 > + default 0x2000e000 if ROCKCHIP_RK3188 > + default 0x110d0020 if ROCKCHIP_RK322X > + default 0xff810020 if ROCKCHIP_RK3288 > + default 0xff1d0020 if ROCKCHIP_RK3328 > + default 0xff830020 if ROCKCHIP_RK3368 > + default 0xff8680a0 if ROCKCHIP_RK3399 > + default 0x10350020 if ROCKCHIP_RV1108 > + default 0 > + help > + The secure timer inited in SPL/TPL in secure word, ARM generic > timer > + works after this timer work. > + > config ROCKCHIP_SPL_RESERVE_IRAM > hex "Size of IRAM reserved in SPL" > default 0 > -- > 1.9.1 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] clk: sunxi: a10: Add CLK_AHB_GMAC
CLK_AHB_GMAC was suppose to be part of previous commit
"clk: sunxi: Implement A10 EMAC clocks" add it so-that
we can get rid of sunxi_set_gate warning on boot message.
Signed-off-by: Jagan Teki
---
drivers/clk/sunxi/clk_a10.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index 15ffe5ecb3..7a96d1708e 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -28,6 +28,8 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_SPI2] = GATE(0x060, BIT(22)),
[CLK_AHB_SPI3] = GATE(0x060, BIT(23)),
+ [CLK_AHB_GMAC] = GATE(0x064, BIT(17)),
+
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
[CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] mx7_common: Share configs to skip low level init
Share configs in mx7 to skip low level init if we are in the case where OPTEE is loaded already (maybe by ARM Trusted Firmware) and that most of the low level initialization is already done and that we may/should skip it doing them here. Fix the definition detection with size detection to decide whether to skip it. Signed-off-by: Jun Nie --- include/configs/mx7_common.h | 11 +++ include/configs/warp7.h | 11 --- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h index a895c93..912fb06 100644 --- a/include/configs/mx7_common.h +++ b/include/configs/mx7_common.h @@ -57,4 +57,15 @@ #endif #endif +/* + * If we have defined the OPTEE ram size and not OPTEE it means that we were + * launched by OPTEE, because of that we shall skip all the low level + * initialization since it was already done by ATF or OPTEE + */ +#if (CONFIG_OPTEE_TZDRAM_SIZE != 0) +#ifndef CONFIG_OPTEE +#define CONFIG_SKIP_LOWLEVEL_INIT +#endif +#endif + #endif diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 043f286..80ddd72 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -13,17 +13,6 @@ #define PHYS_SDRAM_SIZESZ_512M -/* - * If we have defined the OPTEE ram size and not OPTEE it means that we were - * launched by OPTEE, because of that we shall skip all the low level - * initialization since it was already done by ATF or OPTEE - */ -#ifdef CONFIG_OPTEE_TZDRAM_SIZE -#ifndef CONFIG_OPTEE -#define CONFIG_SKIP_LOWLEVEL_INIT -#endif -#endif - #define CONFIG_MXC_UART_BASE UART1_IPS_BASE_ADDR /* Size of malloc() pool */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] pico-imx7d: Add support for BL33 case
Add configuration to boot U-boot as BL33 case. The boot flow is ATF -> OPTEE -> U-boot. Changes vs V1: - Remove DCD file. - Add a patch to fix uart clock root ID. - Change file name from pico-pi-imx7d_bl33_defconfig to pico-imx7d_bl33_defconfig Jun Nie (6): mx7_common: Share configs to skip low level init imx: mx7: Add empty arch_cpu_init if skipped pico-imx7d: Reserve region of memory to OPTEE pico-imx7d: Add boot option for verified boot pico-imx7d: Add bl33 config pico-imx7d: Correct uart clock root arch/arm/include/asm/arch-mx7/clock.h| 5 +++ arch/arm/mach-imx/mx7/clock.c| 2 +- arch/arm/mach-imx/mx7/soc.c | 4 +++ board/technexion/pico-imx7d/pico-imx7d.c | 5 +++ configs/pico-imx7d_bl33_defconfig| 61 include/configs/mx7_common.h | 11 ++ include/configs/pico-imx7d.h | 39 ++-- include/configs/warp7.h | 11 -- 8 files changed, 123 insertions(+), 15 deletions(-) create mode 100644 configs/pico-imx7d_bl33_defconfig -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] pico-imx7d: Add bl33 config
Add default configuration to run u-boot as BL33 in the boot flow case of ATF(ARM Trusted Firmware) -> OPTEE -> U-boot. Signed-off-by: Jun Nie --- configs/pico-imx7d_bl33_defconfig | 61 +++ 1 file changed, 61 insertions(+) create mode 100644 configs/pico-imx7d_bl33_defconfig diff --git a/configs/pico-imx7d_bl33_defconfig b/configs/pico-imx7d_bl33_defconfig new file mode 100644 index 000..77e46d5 --- /dev/null +++ b/configs/pico-imx7d_bl33_defconfig @@ -0,0 +1,61 @@ +CONFIG_ARM=y +CONFIG_ARCH_MX7=y +CONFIG_SYS_TEXT_BASE=0x8780 +CONFIG_SPL_GPIO_SUPPORT=y +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SECURE_BOOT=y +CONFIG_TARGET_PICO_IMX7D=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL=y +CONFIG_ARMV7_BOOT_SEC_DEFAULT=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" +CONFIG_DEFAULT_FDT_FILE="imx7d-pico-pi.dtb" +CONFIG_BOUNCE_BUFFER=y +CONFIG_SPL_I2C_SUPPORT=y +CONFIG_SPL_USB_HOST_SUPPORT=y +CONFIG_SPL_USB_GADGET=y +CONFIG_SPL_USB_SDP_SUPPORT=y +CONFIG_HUSH_PARSER=y +# CONFIG_CMD_BOOTD is not set +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_SPL=y +CONFIG_CMD_SPL_WRITE_SIZE=0x2 +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_SDP=y +CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_DHCP=y +CONFIG_CMD_PXE=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_DFU_MMC=y +CONFIG_FSL_ESDHC=y +CONFIG_PHYLIB=y +CONFIG_MII=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_MXC_USB_OTG_HACTIVE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_CI_UDC=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_USB_ETHER=y +CONFIG_USB_ETH_CDC=y +CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" +CONFIG_OF_LIBFDT=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OPTEE_TZDRAM_SIZE=0x200 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] pico-imx7d: Reserve region of memory to OPTEE
Subtracts CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size so that
the OPTEE memory is not override during u-boot relocation.
Note the OPTEE boot process will itself subtract the DRAM region it lives
in from the memory map passed to Linux.
Signed-off-by: Jun Nie
---
board/technexion/pico-imx7d/pico-imx7d.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c
b/board/technexion/pico-imx7d/pico-imx7d.c
index 53e1469..7c9e145 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -60,6 +60,11 @@ int dram_init(void)
{
gd->ram_size = imx_ddr_size();
+ /* Subtract the defined OPTEE runtime firmware length */
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+ gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
+#endif
+
return 0;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] pico-imx7d: Add boot option for verified boot
Add boot option to boot from fitimage to support verified boot.
The boot script plain text file should be packed into fit blob as
image with name of bootscr.
Signed-off-by: Jun Nie
---
include/configs/pico-imx7d.h | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h
index 1884c58..8eb9064 100644
--- a/include/configs/pico-imx7d.h
+++ b/include/configs/pico-imx7d.h
@@ -52,11 +52,29 @@
"/boot/imx7d-pico-pi.dtb ext4 0 1;" \
"rootfs part 0 1\0" \
-#define BOOTMENU_ENV \
+/* When booting with FIT specify the node entry containing boot.scr */
+#if defined(CONFIG_FIT)
+#define PICO_BOOT_ENV \
+ "bootscr_fitimage_name=bootscr\0" \
+ "bootscriptaddr=0x8320\0" \
+ "fdtovaddr=0x8310\0" \
+ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
+ "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
+ "mmcargs=setenv bootargs console=${console},${baudrate} " \
+ "rootwait rw;\0" \
+ "loadbootscript=" \
+ "load mmc ${mmcdev}:${mmcpart} ${bootscriptaddr} ${script};\0" \
+ "bootscript=echo Running bootscript from mmc ...; " \
+ "source ${bootscriptaddr}:${bootscr_fitimage_name}\0"
+#else
+#define PICO_BOOT_ENV \
"bootmenu_0=Boot using PICO-Hobbit baseboard=" \
"setenv fdtfile imx7d-pico-hobbit.dtb\0" \
"bootmenu_1=Boot using PICO-Pi baseboard=" \
"setenv fdtfile imx7d-pico-pi.dtb\0" \
+ BOOTENV
+#endif
+
#define CONFIG_SUPPORT_EMMC_BOOT /* eMMC specific */
#define CONFIG_SYS_MMC_IMG_LOAD_PART 1
@@ -68,7 +86,6 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
- BOOTMENU_ENV \
"fdt_addr=0x8300\0" \
"fdt_addr_r=0x8300\0" \
"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
@@ -88,7 +105,22 @@
"name=rootfs,size=0,uuid=${uuid_gpt_rootfs}\0" \
"fastboot_partition_alias_system=rootfs\0" \
"setup_emmc=mmc dev 0; gpt write mmc 0 $partitions; reset;\0" \
- BOOTENV
+ PICO_BOOT_ENV
+
+#if defined(CONFIG_FIT)
+#define CONFIG_BOOTCOMMAND \
+ "mmc dev ${mmcdev};" \
+ "mmc dev ${mmcdev}; if mmc rescan; then " \
+ "if run loadbootscript; then " \
+ "iminfo ${bootscriptaddr};" \
+ "if test $? -eq 1; then hab_failsafe; fi;" \
+ "run bootscript; " \
+ "else " \
+ "echo Fail to load fitImage with boot script;" \
+ "hab_failsafe;" \
+ "fi; " \
+ "fi"
+#endif
#define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] imx: mx7: Add empty arch_cpu_init if skipped
Add empty arch_cpu_init if low level init is skipped. So that
it does not break spl compile though spl is not needed in the
skipped case actually.
Signed-off-by: Jun Nie
---
arch/arm/mach-imx/mx7/soc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 7cfdff0..9b04013 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -286,6 +286,11 @@ int arch_cpu_init(void)
return 0;
}
+#else
+int arch_cpu_init(void)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_ARCH_MISC_INIT
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] pico-imx7d: Correct uart clock root
Correct uart clock root ID. Incorrect ID may result the
clock is gated because rate value 0 is returned in
imx_get_uartclk()
Signed-off-by: Jun Nie
---
arch/arm/include/asm/arch-mx7/clock.h | 5 +
arch/arm/mach-imx/mx7/clock.c | 2 +-
include/configs/pico-imx7d.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-mx7/clock.h
b/arch/arm/include/asm/arch-mx7/clock.h
index f56564e..b6a1768 100644
--- a/arch/arm/include/asm/arch-mx7/clock.h
+++ b/arch/arm/include/asm/arch-mx7/clock.h
@@ -175,6 +175,11 @@ enum clk_root_index {
CLK_ROOT_MAX,
};
+/* Use UART1_CLK_ROOT as default root clk if platform does define it */
+#ifndef UART_CLK_ROOT
+#define UART_CLK_ROOT UART1_CLK_ROOT
+#endif
+
struct clk_root_setting {
enum clk_root_index root;
u32 setting;
diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c
index 8cda71c..e364b16 100644
--- a/arch/arm/mach-imx/mx7/clock.c
+++ b/arch/arm/mach-imx/mx7/clock.c
@@ -53,7 +53,7 @@ static u32 get_ipg_clk(void)
u32 imx_get_uartclk(void)
{
- return get_root_clk(UART1_CLK_ROOT);
+ return get_root_clk(UART_CLK_ROOT);
}
u32 imx_get_fecclk(void)
diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h
index 8eb9064..9806348 100644
--- a/include/configs/pico-imx7d.h
+++ b/include/configs/pico-imx7d.h
@@ -28,6 +28,7 @@
#define CONFIG_SYS_MALLOC_LEN (32 * SZ_1M)
#define CONFIG_MXC_UART_BASE UART5_IPS_BASE_ADDR
+#define UART_CLK_ROOT UART5_CLK_ROOT
/* Network */
#define CONFIG_FEC_MXC
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] configs: am57xx_evm: Remove ENV_IS_IN_FAT
With U-boot supporting environment in multiple places, enable only ENV_IS_IN_EMMC. Signed-off-by: Faiz Abbas --- configs/am57xx_evm_defconfig| 1 + configs/am57xx_hs_evm_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig index 3d71020225..e4f0458d72 100644 --- a/configs/am57xx_evm_defconfig +++ b/configs/am57xx_evm_defconfig @@ -35,6 +35,7 @@ CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="am572x-idk" CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 am57xx-beagle-x15-revc am572x-idk am571x-idk am574x-idk" +# CONFIG_ENV_IS_IN_FAT is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_DM=y diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig index 9b71afa312..157ae1ea1c 100644 --- a/configs/am57xx_hs_evm_defconfig +++ b/configs/am57xx_hs_evm_defconfig @@ -38,6 +38,7 @@ CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15" CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 am57xx-beagle-x15-revc am572x-idk am571x-idk am574x-idk" +# CONFIG_ENV_IS_IN_FAT is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_DM=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: dts: dra7: Change pbias voltage to 3.3V
As per recent TRM[1], PBIAS cell on dra7 devices supports
3.3v and not 3.0v as documented earlier.
Update PBIAS regulator max voltage and the voltage written
in the driver to reflect this.
[1] http://www.ti.com/lit/pdf/sprui30
Signed-off-by: Faiz Abbas
---
arch/arm/dts/dra7.dtsi| 2 +-
drivers/power/regulator/pbias_regulator.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/dra7.dtsi b/arch/arm/dts/dra7.dtsi
index 0f982d8b44..fd1aea0b1b 100644
--- a/arch/arm/dts/dra7.dtsi
+++ b/arch/arm/dts/dra7.dtsi
@@ -170,7 +170,7 @@
pbias_mmc_reg: pbias_mmc_omap5 {
regulator-name =
"pbias_mmc_omap5";
regulator-min-microvolt
= <180>;
- regulator-max-microvolt
= <300>;
+ regulator-max-microvolt
= <330>;
};
};
diff --git a/drivers/power/regulator/pbias_regulator.c
b/drivers/power/regulator/pbias_regulator.c
index 4ed3c94e03..88dc9f273a 100644
--- a/drivers/power/regulator/pbias_regulator.c
+++ b/drivers/power/regulator/pbias_regulator.c
@@ -238,7 +238,7 @@ static int pbias_regulator_set_value(struct udevice *dev,
int uV)
if (rc)
return rc;
- if (uV == 300)
+ if (uV == 330)
reg |= p->vmode;
else if (uV == 180)
reg &= ~p->vmode;
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Update pbias and IO voltage in dra7 and am57 devices
The following patches update pbias and IO voltages in TI's dra7 and am57 devices. Tested on: dra71x-evm, dra72x-evm, dra7xx-evm, dra76x-evm, am57xx-evm, am571-idk, am572-idk, am574-idk, am335x-evm. Faiz Abbas (2): ARM: dts: dra7: Change pbias voltage to 3.3V mmc: omap_hsmmc: Set 3.3V for IO voltage arch/arm/dts/dra7.dtsi| 2 +- drivers/mmc/omap_hsmmc.c | 21 ++--- drivers/power/regulator/pbias_regulator.c | 2 +- 3 files changed, 12 insertions(+), 13 deletions(-) -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mmc: omap_hsmmc: Set 3.3V for IO voltage
Pbias voltage should match the IO voltage set for the SD card. With the
latest pbias change to 3.3V, update the capabilities and IO voltages
settings to 3.3V.
Signed-off-by: Faiz Abbas
---
drivers/mmc/omap_hsmmc.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 826a39fad7..133cdc1352 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -264,7 +264,7 @@ static unsigned char mmc_board_init(struct mmc *mmc)
!CONFIG_IS_ENABLED(DM_REGULATOR)
/* PBIAS config needed for MMC1 only */
if (mmc_get_blk_desc(mmc)->devnum == 0)
- vmmc_pbias_config(LDO_VOLT_3V0);
+ vmmc_pbias_config(LDO_VOLT_3V3);
#endif
return 0;
@@ -418,7 +418,7 @@ static void omap_hsmmc_conf_bus_power(struct mmc *mmc, uint
signal_voltage)
switch (signal_voltage) {
case MMC_SIGNAL_VOLTAGE_330:
- hctl |= SDVS_3V0;
+ hctl |= SDVS_3V3;
break;
case MMC_SIGNAL_VOLTAGE_180:
hctl |= SDVS_1V8;
@@ -514,10 +514,9 @@ static int omap_hsmmc_set_signal_voltage(struct mmc *mmc)
return -EINVAL;
if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
- /* Use 3.0V rather than 3.3V */
- mv = 3000;
- capa_mask = VS30_3V0SUP;
- palmas_ldo_volt = LDO_VOLT_3V0;
+ mv = 3300;
+ capa_mask = VS33_3V3SUP;
+ palmas_ldo_volt = LDO_VOLT_3V3;
} else if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
capa_mask = VS18_1V8SUP;
palmas_ldo_volt = LDO_VOLT_1V8;
@@ -556,13 +555,13 @@ static uint32_t omap_hsmmc_set_capabilities(struct mmc
*mmc)
val = readl(&mmc_base->capa);
if (priv->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
- val |= (VS30_3V0SUP | VS18_1V8SUP);
+ val |= (VS33_3V3SUP | VS18_1V8SUP);
} else if (priv->controller_flags & OMAP_HSMMC_NO_1_8_V) {
- val |= VS30_3V0SUP;
+ val |= VS33_3V3SUP;
val &= ~VS18_1V8SUP;
} else {
val |= VS18_1V8SUP;
- val &= ~VS30_3V0SUP;
+ val &= ~VS33_3V3SUP;
}
writel(val, &mmc_base->capa);
@@ -842,11 +841,11 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
#if CONFIG_IS_ENABLED(DM_MMC)
reg_val = omap_hsmmc_set_capabilities(mmc);
- omap_hsmmc_conf_bus_power(mmc, (reg_val & VS30_3V0SUP) ?
+ omap_hsmmc_conf_bus_power(mmc, (reg_val & VS33_3V3SUP) ?
MMC_SIGNAL_VOLTAGE_330 : MMC_SIGNAL_VOLTAGE_180);
#else
writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V0, &mmc_base->hctl);
- writel(readl(&mmc_base->capa) | VS30_3V0SUP | VS18_1V8SUP,
+ writel(readl(&mmc_base->capa) | VS33_3V3SUP | VS18_1V8SUP,
&mmc_base->capa);
#endif
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Move Stratix 10 SDRAM driver to DM
On Thu, Mar 28, 2019 at 3:06 AM Ley Foon Tan wrote:
>
> On Wed, Mar 27, 2019 at 7:34 PM Simon Goldschmidt
> wrote:
> >
> > On Wed, Mar 27, 2019 at 10:15 AM Ley Foon Tan
> > wrote:
> > >
> > > Convert Stratix 10 SDRAM driver to device model.
> >
> > Nice to see that :-)
> >
> > >
> > > Get rid of call to socfpga_per_reset() and use reset
> > > framework.
> > >
> > > SPL is changed from calling function in SDRAM driver
> > > directly to just probing UCLASS_RAM.
> > >
> > > Move sdram_s10.h from arch to driver/ddr/altera directory.
> > >
> > > Signed-off-by: Ley Foon Tan
> > > ---
> > > arch/arm/Kconfig | 4 +-
> > > arch/arm/dts/socfpga_stratix10.dtsi | 10 +
> > > arch/arm/dts/socfpga_stratix10_socdk.dts | 4 +
> > > arch/arm/mach-socfpga/Kconfig | 1 +
> > > arch/arm/mach-socfpga/spl_s10.c | 9 +-
> > > drivers/ddr/altera/Kconfig| 2 +-
> > > drivers/ddr/altera/sdram_s10.c| 246 --
> > > .../mach => drivers/ddr/altera}/sdram_s10.h | 4 -
> > > include/configs/socfpga_stratix10_socdk.h | 5 -
> > > 9 files changed, 195 insertions(+), 90 deletions(-)
> > > rename {arch/arm/mach-socfpga/include/mach =>
> > > drivers/ddr/altera}/sdram_s10.h (97%)
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 77a534f81fd..a2d4f7f4c25 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -821,14 +821,14 @@ config ARCH_SOCFPGA
> > > select DM_SERIAL
> > > select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 ||
> > > TARGET_SOCFPGA_ARRIA10
> > > select OF_CONTROL
> > > - select RAM if TARGET_SOCFPGA_GEN5
> > > + select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> > > select SPL_DM_RESET if DM_RESET
> > > select SPL_DM_SERIAL
> > > select SPL_LIBCOMMON_SUPPORT
> > > select SPL_LIBGENERIC_SUPPORT
> > > select SPL_NAND_SUPPORT if SPL_NAND_DENALI
> > > select SPL_OF_CONTROL
> > > - select SPL_RAM if TARGET_SOCFPGA_GEN5
> > > + select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> > > select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
> > > select SPL_SERIAL_SUPPORT
> > > select SPL_WATCHDOG_SUPPORT
> > > diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> > > b/arch/arm/dts/socfpga_stratix10.dtsi
> > > index ee93725d648..15d0f88f182 100644
> > > --- a/arch/arm/dts/socfpga_stratix10.dtsi
> > > +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> > > @@ -245,6 +245,16 @@
> > > u-boot,dm-pre-reloc;
> > > };
> > >
> > > + sdr: sdr@f8000400 {
> > > +compatible = "altr,sdr-ctl-s10";
> > > +reg = <0xf8000400 0x80>,
> > > + <0xf801 0x190>,
> > > + <0xf8011000 0x500>;
> > > +resets = <&rst DDRSCH_RESET>;
> > > +u-boot,dm-pre-reloc;
> > > +status = "disabled";
> >
> > Why is this optional? The SPL won't work without that any more by default,
> > or would it? I would have thought it's enabled by default?
> Customer can use either SDRAM controller in HPS or in FPGA.
> We don't need this driver if SDRAM controller is in FPGA. All
> initialization process will handled by HW.
> I think we just need a very simple sdram driver for sdram controller
> in FPGA, just to setup get_info().
Fair enough. But how often will this be used? Would it make sense to use the
internal SDRAM controller by default and let the customers with a controller
in the FPGA override it or is this a common use case?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: getvar: fix broken 'fastboot flash' when partition has slots
On Wed, Mar 27, 2019 at 12:32 PM Eugeniu Rosca wrote:
>
> Hi Alex,
>
> Thanks for the precious comments. Some remarks below.
>
> On Wed, Mar 27, 2019 at 05:55:51AM +, Alex Kiernan wrote:
> > On Wed, Mar 27, 2019 at 5:44 AM Alex Kiernan wrote:
> > > On Wed, Mar 27, 2019 at 1:04 AM Eugeniu Rosca
> > > wrote:
> [..]
> > > > diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> > > > index 4d264c985d7e..03bcd7162b37 100644
> > > > --- a/drivers/fastboot/fb_getvar.c
> > > > +++ b/drivers/fastboot/fb_getvar.c
> > > > @@ -130,8 +130,17 @@ static void getvar_slot_suffixes(char
> > > > *var_parameter, char *response)
> > > >
> > > > static void getvar_has_slot(char *part_name, char *response)
> > > > {
> > > > - if (part_name && (!strcmp(part_name, "boot") ||
> > > > - !strcmp(part_name, "system")))
> > > > + struct blk_desc *dev_desc;
> > > > + disk_partition_t info;
> > > > + char name[32];
> > >
> > > For the code as written this needs to be 33, or the strcat can
> > > overflow by 1.
> >
> > Sorry, wrong way around... can truncate the name by 1, not overflow.
>
> Applying below two-liner instrumentation on top of my patch:
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index c703be4cd61e..0149824c0d3d 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -138,7 +138,9 @@ static void getvar_has_slot(char *part_name, char
> *response)
> return;
>
> strlcpy(name, part_name, sizeof(name) - 2);
> + printf("%s: name: %s, strlen(name) %lu\n", __func__, name,
> strlen(name));
> strcat(name, "_a");
> + printf("%s: name: %s, strlen(name) %lu\n", __func__, name,
> strlen(name));
>
> if (fastboot_mmc_get_part_info(name, &dev_desc, &info, response) >= 0)
> fastboot_okay("yes", response);
>
> Passing a 32+ character part-name to 'getvar has-slot' results in:
> $ host> fastboot getvar
> has-slot:0123456789abcdef0123456789abcdef0123456789abcdef
> $ target>
> getvar_has_slot: name: 0123456789abcdef0123456789abc, strlen(name) 29
> getvar_has_slot: name: 0123456789abcdef0123456789abc_a, strlen(name) 31
>
> From the above results, it looks to me that the partition name handling
> (including deliberate string truncation done by strlcpy) works
> correctly. I am still ready to rework/optimize the implementation if
> you have any concerns/counter-proposals.
>
Looking at the rest of the code, there's confusion as to whether it's
expecting a +1 or not, given disk_partition.name[] is PART_NAME_LEN, I
think what you have is right.
> >
> > > Also we should use PART_NAME_LEN not 32 (fb_mmc.c needs
> > > fixing in the same way).
>
> Agreed. Will be fixed in v2.
>
> > > > +
> > > > + if (!part_name || !strcmp(part_name, ""))
> > > > + return;
> > >
> > > This needs to do fastboot_okay/fastboot_fail or you'll get the
> > > protocol out of sync
>
> The idea was to avoid bloating U-Boot with string literals, but I can
> add a fastboot_fail() call if you wish so. IMO if the lack of
> fastboot_okay/fastboot_fail at the end of dispatching a fastboot call
> triggers undefined behavior on host side, then long-term this should
> be fixed in the U-Boot fastboot dispatcher itself. FWIW, the current
> behavior on my target is:
>
> host $> fastboot getvar has-slot
> getvar:has-slot FAILED (status malformed (0 bytes))
> Finished. Total time: 0.039s
> host $> fastboot getvar has-slot:
> getvar:has-slot: FAILED (status malformed (0 bytes))
> Finished. Total time: 0.039s
>
"status malformed" is a pretty poor failure. The other thing is check
both the UDP and USB paths - the UDP path gets stuck in timeouts if
you don't send something which is within the protocol (though probably
not for this case).
I'd agree that the structure is awkward - if you're looking at
implementing `getvar all` then I expect it all have to be refactored
as my recollection is for multiple values you have to send them as
INFO frames.
> > > > +
> > > > + strlcpy(name, part_name, sizeof(name) - 2);
> > > > + strcat(name, "_a");
> > > > +
> > > > + if (fastboot_mmc_get_part_info(name, &dev_desc, &info,
> > > > response) >= 0)
> > > > fastboot_okay("yes", response);
> > > > else
> > > > fastboot_okay("no", response);
> > >
> > > This will fail if you're building with CONFIG_FASTBOOT_FLASH_NAND.
>
> Agreed. Has to be fixed in v2. Do you have any preference between
> the build-time "#if CONFIG_IS_ENABLED()" and the run-time "IS_ENABLED()"
> which will be needed for NAND-specific handling? It is my feeling that
> in Linux realm the run-time checks are greatly preferred. Here is some
> feedback from Stephen Rothwell in https://lkml.org/lkml/2018/2/22/406:
>
I guess my preference is for consistency within a subsystem;
personally I prefer the IS_ENABLED() style, but I suspect there's some
refactoring ne
Re: [U-Boot] [PATCH 3/3] rockchip: correct ARCH_SOC name
Hi Philipp, On 03/28/2019 03:02 PM, Philipp Tomsich wrote: > >> On 28.03.2019, at 04:01, Kever Yang wrote: >> >> The ARCH_SOC name default as 'rockchip' and we put all the >> header file in 'arch/arm/include/asm/arch-rockchip/', but >> the 'rockchip' is not the SOC name, let's correct it after >> we update all the source file. >> >> Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsiich > > Just a style question: most of the documentation refers to the chips as RK3… > while this has them as rk3… (i.e. the differenc eis whether the RK is lower- > or upper-case); is this difference intentional? This soc name will use to mach rk3...dtsi in source code, and all the dtsi files are using lower-case. Thanks, - Kever > > Thanks, > Phil. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] rockchip: arm: remove no use macro
TIMER7_BASE is no used by source code now, remove it. Signed-off-by: Kever Yang --- arch/arm/include/asm/arch-rockchip/hardware.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/hardware.h b/arch/arm/include/asm/arch-rockchip/hardware.h index cd94bdd1ba..62e8bed8f3 100644 --- a/arch/arm/include/asm/arch-rockchip/hardware.h +++ b/arch/arm/include/asm/arch-rockchip/hardware.h @@ -10,8 +10,6 @@ #define RK_SETBITS(set)RK_CLRSETBITS(0, set) #define RK_CLRBITS(clr)RK_CLRSETBITS(clr, 0) -#define TIMER7_BASE0xff810020 - #define rk_clrsetreg(addr, clr, set) \ writel(((clr) | (set)) << 16 | (set), addr) #define rk_clrreg(addr, clr) writel((clr) << 16, addr) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] raspberrypi0w issue when change cmdline.txt -> FDT_ERR_BADMAGIC
Hi, I'm having strange issue that when update cmdline.txt in boot partition (basically after first boot there is resize of data partition) then I get this: U-Boot 2018.07-g981cc831e3 (Mar 26 2019 - 11:14:55 +0100) DRAM: 448 MiB RPI Zero W (0x9000c1) MMC: sdhci@7e30: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment Failed (-5) Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 300 bytes read in 6 ms (48.8 KiB/s) ## Executing script at 0240 libfdt fdt_check_header(): FDT_ERR_BADMAGIC switch to partitions #0, OK mmc0 is current device 4688856 bytes read in 307 ms (14.6 MiB/s) Kernel image @ 0x08 [ 0x00 - 0x478bd8 ] ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree SCRIPT FAILED: continuing... starting USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found when checking fdt_addr there was no dtb loaded at all (juts 0xaa on that address). When remove resize from cmdline.txt before booting then board boots fine. Any ideas if broadcom FW can change something in that regard and break things? Thanks for any pointers. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rockchip: arm: remove no use macro
> On 28.03.2019, at 10:36, Kever Yang wrote: > > TIMER7_BASE is no used by source code now, remove it. > > Signed-off-by: Kever Yang Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] saveenv corrupts QSPI flash with latest commit U-Boot 2019.04-rc4-00047-gcfb3e102c4
> -Original Message-
> From: Vignesh Raghavendra
> Sent: Wednesday, March 27, 2019 9:44 AM
> To: Ashish Kumar ; Jagan Teki
> ; u-boot@lists.denx.de; Tom Rini
>
> Cc: Kuldeep Singh
> Subject: Re: saveenv corrupts QSPI flash with latest commit U-Boot
> 2019.04-rc4-
> 00047-gcfb3e102c4
>
>
>
> On 26/03/19 7:11 PM, Ashish Kumar wrote:
> >>
> >> On 26/03/19 10:36 AM, Ashish Kumar wrote:
> >>> Hello Maintainers,
> >>>
> >>>
> >>>
> >>> With latest commit I see that saveenv command corrupts QSPI-flash,
> >>> meaning if I read QSPI-flash at 0x0 offset RCW(reset configuration
> >>> word) is erased after saveenv command was executed.
> >>>
> >>> This is tested on LS1088ARDB, but it should not be limited to
> >>> LS1088ARDB rather it will valid for all LS Freescale ARM boards.(
> >>> like LS1088, LS2080/LS2085, LS1012, LS1043, LS1046).
> >>>
> >>
> >> Which is the SPI controller driver? Does the controller driver
> >> support reading/writing to flash using 4 byte addressing opcode?
> >
> > fsl_qspi.c. As per the migration it was not migrated to 4 byte. Although it
> actually supports 4 byte for some SoC and 3 byte for older SoC that is the
> reason
> you see CONFIG_SPI_FLASH_BAR in code. My concerned SoC are all supporting
> 4 byte. I have not added any code modification in the current u-boot.
> >>
>
> OK, does normal read/write to offset 0 work fine? That is:
>
> sf probe
> sf erase 0x0 4
> sf write 0x0 0x4 (write some random data) sf read 0x0
> 0x4 (read back) md.b
>
> If this fails. Could you post full debug log (all debug prints enabled in
> spi_mem_exec_op()) to pastebin.ubuntu.com and provide a link here?
Hi Vignesh,
This is working now(READ, WRITE), after some change in fsl_qspi driver, where I
check for 4byte op codes now.
But now I see that erase is getting address as ZERO. Which in my opinion is
because
spi_nor_erase_sector() call write_reg which has SPI_MEM_OP_NO_ADDR?
/*
* Initiate the erasure of a single sector
*/
static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr)
{
u8 buf[SPI_NOR_MAX_ADDR_WIDTH];
int i;
if (nor->erase)
return nor->erase(nor, addr);
/*
* Default implementation, if driver doesn't have a specialized HW
* control
*/
for (i = nor->addr_width - 1; i >= 0; i--) {
buf[i] = addr & 0xff;
addr >>= 8;
}
return nor->write_reg(nor, nor->erase_opcode, buf, nor->addr_width);
}
static int spi_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
{
struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 1),
SPI_MEM_OP_NO_ADDR,
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_OUT(len, NULL, 1));
return spi_nor_read_write_reg(nor, &op, buf);
}
Regards
Ashish
>
> >> Could you enable all the debug prints in spi_mem_exec_op()
> >> (especially those at the end)?
> > Logs are very verbose: I have commented two debug logs which are in
> > for loop Logs here are from the end, 0b 33 f3 43 | [59B in] [ret 0]
>
> I dont know the address from which saveenv is trying to read from. But does
> the
> address bytes match (33 f3 43)?
>
> [...]
> > 0b 33 ff f0 | [16B in] [ret 0]
> > Erasing SPI flash...06 | [0B -] [ret 0]
> > d8 | [3B out] [ret 0]
>
>
> This is the sector erase command but you haven't enabled log for the
> part where address of the sector is dumped. Could you provide that info?
>
> Also, the commit ID in the subject is not present in upstream tree. So I
> am not sure what exactly maybe broken. Does 2019.01 work fine?
> U-Boot had major sf layer refactoring in 2019.04-rc1. Could you see if
> 2019.04-rc1 works fine?
>
>
>
>
> --
> Regards
> Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] travis-ci: fix at91 missing boards
From: Eugen Hristev Fix missing at91 boards and split the at91 in two categories: at91 arm v7 at91 arm926esj which are the two main cores for the at91 architecture. Signed-off-by: Eugen Hristev --- Hello, I am not very good with Travis, I added this because buildman atmel has lesser total boards than buildman at91. buildman at91 has 78 boards so I split into two tasks, to avoid hitting the 50minutes limit on travis build. Here is a link to travis with this patch applied: https://travis-ci.org/ehristev/u-boot/builds/511575257 Thanks .travis.yml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index 834502f..6179689 100644 --- a/.travis.yml +++ b/.travis.yml @@ -167,9 +167,12 @@ matrix: env: - JOB="arm926ejs" BUILDMAN="arm926ejs -x freescale,siemens,atmel,kirkwood,spear,omap" -- name: "buildman atmel" +- name: "buildman at91 (non arm v7)" env: -- BUILDMAN="atmel" +- BUILDMAN="at91 -x armv7" +- name: "buildman at91 (non arm926ejs)" + env: +- BUILDMAN="at91 -x arm926ejs" - name: "buildman boundary engicam toradex" env: - BUILDMAN="boundary engicam toradex" -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: getvar: fix broken 'fastboot flash' when partition has slots
Hi Alex, Thanks yet again for the timely and insightful replies. I'll be sending out a v2 tackling your review findings as soon as I can. Best regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [REGRESSION: PATCH 34/34] drivers/net/fec: phy_init: remove redundant logic
Dear Tom, Marcel, Stefano
> Hi Marcel,
>
> > Hi Stefano
> >
> > On Wed, 2019-03-13 at 08:28 +, sba...@denx.de wrote:
> > > > The phy_connect_dev(...) function from phy.c does all the
> > > > handling (inclusive catching fixed-link).
> > > > So we drop here the single steps and call just
> > > > phy_connect_dev(...).
> > > > Signed-off-by: Hannes Schmelzer
> > > > > > > >
> > > > Acked-by: Joe Hershberger
> > >
> > > Applied to u-boot-imx, master, thanks !
> > >
> > > Best regards,
> > > Stefano Babic
> >
> > Unfortunately, this commit broke Ethernet on the Vybrid. When
> > re-basing my Colibri VF50/VF61 clean-up patch set ("colibri vybrid
> > fixes, device tree enablement and driver model conversion") I
> > noticed that Ethernet no longer works giving the following error
> > messages:
> >
> > Net: Could not get PHY for FEC0: addr -19
> > eth-1: fec@400d1000
> > Colibri VFxx # dhcp
> > Could not get PHY for FEC0: addr -19
> > Could not get PHY for FEC0: addr -19
> > Could not get PHY for FEC0: addr -19
> > Could not get PHY for FEC0: addr -19
> > No ethernet found.
> > Could not get PHY for FEC0: addr -19
> > Colibri VFxx #
> >
> > Bisecting points to this commit and reverting it indeed makes it
> > work again.
> >
> > Has anybody else seen a similar issue (e.g. @Lukasz on pcm052)?
>
> I did not checked yet - as I was waiting for the code to settle down
> to mainline (after the v2019.04 u-boot release).
>
> I will check it on bk4.
Maybe not on BK4, but surely on (HSC):
CPU: Freescale i.MX53 rev2.1 at 800 MHz
=> dhcp
Could not get PHY for FEC0: addr -19
Could not get PHY for FEC0: addr -19
Could not get PHY for FEC0: addr -19
Could not get PHY for FEC0: addr -19
No ethernet found.
Could not get PHY for FEC0: addr -19
I can confirm the error.
So I do expect that we have some more IMX boards broken (imx53, vybrid).
I think that it would be best to revert this patch before v2019.04
release and look for clean up opportunities afterwards.
>
> >
> > Cheers
> >
> > Marcel
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpW2_JnjJ4E3.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/10] rockchip: enable board_debug_uart_init for all soc
Hi Philipp, Ping again. I search the patchwork again for this patch set, and most of them get your tags: 'Reviewed-by' and 'Acked-by', and I didn't see any change request for it, can I just rebase them and re-send them? It has been almost 1 year after I send out my patch set. Thanks, - Kever Kever Yang 于2018年8月23日周四 下午6:26写道： > Hi Philipp, > What kind of update do I need to do for this patch set? I didn't get > response mail for this patch set after some search(maybe I didn't do it > correctly). I'm sorry my local mail client only have one month data. > I can do the update upon the comments/request for it, or just re-send > it base on latest U-Boot. > > Thanks, > - Kever > > > Kever Yang 于2018年4月20日周五 下午12:41写道： > >> >> ALl rockchip soc use DEBUG UART, and need init the uart iomux >> in board_debug_uart_init(). >> Move the board_debug_uart_init() into soc file so that we can >> make all soc config in soc file and share a common board file >> later for all rockchip SoCs. >> >> >> >> Kever Yang (10): >> rockchip: enable DEBUG_UART_BOARD_INIT by default >> rockchip; kylin-rk3036: enabl DEBUG UART >> rockchip: rk3036: add board_debug_uart_init() >> rockchip: rk3188: add board_debug_uart_init() >> rockchip: rk322x: move board_debug_uart_init() to rk322x.c >> rockchip: rk3288: use grf structure to access soc_con2 >> rockchip: rk3288: add board_debug_uart_init() >> rockchip: rk3368: move board_debug_uart_init() to rk3368.c >> rockchip: rk3399: use grf structure to access reg >> rockchip: rk3399: add board_debug_uart_init() >> >> arch/arm/Kconfig | 2 ++ >> arch/arm/mach-rockchip/Kconfig| 3 --- >> arch/arm/mach-rockchip/rk3036-board-spl.c | 19 + >> arch/arm/mach-rockchip/rk3036/Makefile| 1 + >> arch/arm/mach-rockchip/rk3036/rk3036.c| 40 >> +++ >> arch/arm/mach-rockchip/rk3188-board-spl.c | 12 + >> arch/arm/mach-rockchip/rk3188/Makefile| 1 + >> arch/arm/mach-rockchip/rk3188/rk3188.c| 37 + >> arch/arm/mach-rockchip/rk322x-board-spl.c | 43 >> ++--- >> arch/arm/mach-rockchip/rk322x-board.c | 31 + >> arch/arm/mach-rockchip/rk322x/Makefile| 2 +- >> arch/arm/mach-rockchip/rk322x/rk322x.c| 45 >> +++ >> arch/arm/mach-rockchip/rk3288-board-spl.c | 11 ++-- >> arch/arm/mach-rockchip/rk3288-board-tpl.c | 13 ++--- >> arch/arm/mach-rockchip/rk3288/rk3288.c| 19 +++-- >> arch/arm/mach-rockchip/rk3368-board-spl.c | 5 >> arch/arm/mach-rockchip/rk3368-board-tpl.c | 33 +-- >> arch/arm/mach-rockchip/rk3368/rk3368.c| 31 + >> arch/arm/mach-rockchip/rk3399-board-spl.c | 31 + >> arch/arm/mach-rockchip/rk3399/rk3399.c| 34 ++- >> configs/kylin-rk3036_defconfig| 4 +++ >> 21 files changed, 223 insertions(+), 194 deletions(-) >> create mode 100644 arch/arm/mach-rockchip/rk3036/rk3036.c >> create mode 100644 arch/arm/mach-rockchip/rk3188/rk3188.c >> create mode 100644 arch/arm/mach-rockchip/rk322x/rk322x.c >> >> -- >> 1.9.1 >> >> ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] board/raspberrypi/rpi/MAINTAINERS
Hello Matthias, in board/raspberrypi/rpi/MAINTAINERS there is still Alex's old email address. Are you also picking up maintainership for those files? Guillaume was asking yesterday on the IRC channel. Cf. https://lists.denx.de/pipermail/u-boot/2019-February/358939.html Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Antwort: Re: [REGRESSION: PATCH 34/34] drivers/net/fec: phy_init: remove redundant logic
HI Lukas,
please can you test with this patch:
But i agree, for 2019.04 it would be ok reverting this and then look if
the provided patch can be applied.
Joe, what do you mean?
cheers,
Hannes
Lukasz Majewski schrieb am 28.03.2019 11:47:34:
> Von: Lukasz Majewski
> An: Marcel Ziswiler , "sba...@denx.de"
> , Tom Rini
> Kopie: "u-boot@lists.denx.de" ,
"hannes.schmelzer@br-
> automation.com" , Joe Hershberger
>
> Datum: 28.03.2019 11:47
> Betreff: Re: [REGRESSION: PATCH 34/34] drivers/net/fec: phy_init: remove
redundant logic
>
> Dear Tom, Marcel, Stefano
>
> > Hi Marcel,
> >
> > > Hi Stefano
> > >
> > > On Wed, 2019-03-13 at 08:28 +, sba...@denx.de wrote:
> > > > > The phy_connect_dev(...) function from phy.c does all the
> > > > > handling (inclusive catching fixed-link).
> > > > > So we drop here the single steps and call just
> > > > > phy_connect_dev(...).
> > > > > Signed-off-by: Hannes Schmelzer
> > > > > > > > > >
> > > > > Acked-by: Joe Hershberger
> > > >
> > > > Applied to u-boot-imx, master, thanks !
> > > >
> > > > Best regards,
> > > > Stefano Babic
> > >
> > > Unfortunately, this commit broke Ethernet on the Vybrid. When
> > > re-basing my Colibri VF50/VF61 clean-up patch set ("colibri vybrid
> > > fixes, device tree enablement and driver model conversion") I
> > > noticed that Ethernet no longer works giving the following error
> > > messages:
> > >
> > > Net: Could not get PHY for FEC0: addr -19
> > > eth-1: fec@400d1000
> > > Colibri VFxx # dhcp
> > > Could not get PHY for FEC0: addr -19
> > > Could not get PHY for FEC0: addr -19
> > > Could not get PHY for FEC0: addr -19
> > > Could not get PHY for FEC0: addr -19
> > > No ethernet found.
> > > Could not get PHY for FEC0: addr -19
> > > Colibri VFxx #
> > >
> > > Bisecting points to this commit and reverting it indeed makes it
> > > work again.
> > >
> > > Has anybody else seen a similar issue (e.g. @Lukasz on pcm052)?
> >
> > I did not checked yet - as I was waiting for the code to settle down
> > to mainline (after the v2019.04 u-boot release).
> >
> > I will check it on bk4.
>
> Maybe not on BK4, but surely on (HSC):
> CPU: Freescale i.MX53 rev2.1 at 800 MHz
>
> => dhcp
> Could not get PHY for FEC0: addr -19
> Could not get PHY for FEC0: addr -19
> Could not get PHY for FEC0: addr -19
> Could not get PHY for FEC0: addr -19
> No ethernet found.
> Could not get PHY for FEC0: addr -19
>
> I can confirm the error.
>
> So I do expect that we have some more IMX boards broken (imx53, vybrid).
>
> I think that it would be best to revert this patch before v2019.04
> release and look for clean up opportunities afterwards.
>
>
>
> >
> > >
> > > Cheers
> > >
> > > Marcel
> >
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lu...@denx.de
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
> [Anhang "att09yen.dat" gelöscht von Hannes Schmelzer/Gilgenberg/AT/B&R]
0001-drivers-net-phy-catch-negative-phy-adresses.patch
Description: Binary data
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [V6 PATCH 3/3] sunxi: Use clrsetbits_le32 instead of multiple instruction
On Mon, Mar 25, 2019 at 6:17 PM Shyam Saini wrote: > > From: Michael Trimarchi > > This will improve code readabilty > > Signed-off-by: Michael Trimarchi > Signed-off-by: Shyam Saini > --- Is this patch on master? couldn't apply at all? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/10] rockchip: enable board_debug_uart_init for all soc
Last I remember was that I had requested a rebase, as they didn’t apply cleanly any longer. > On 28.03.2019, at 11:52, Kever Yang wrote: > > Hi Philipp, > > Ping again. > I search the patchwork again for this patch set, and most of them get your > tags: 'Reviewed-by' and 'Acked-by', and I didn't see any change request for > it, can I just rebase them and re-send them? It has been almost 1 year after > I send out my patch set. > > Thanks, > - Kever > Kever Yang mailto:kever.y...@rock-chips.com>> > 于2018年8月23日周四 下午6:26写道： > Hi Philipp, > What kind of update do I need to do for this patch set? I didn't get > response mail for this patch set after some search(maybe I didn't do it > correctly). I'm sorry my local mail client only have one month data. > I can do the update upon the comments/request for it, or just re-send it > base on latest U-Boot. > > Thanks, > - Kever > > > Kever Yang mailto:kever.y...@rock-chips.com>> > 于2018年4月20日周五 下午12:41写道： > > ALl rockchip soc use DEBUG UART, and need init the uart iomux > in board_debug_uart_init(). > Move the board_debug_uart_init() into soc file so that we can > make all soc config in soc file and share a common board file > later for all rockchip SoCs. > > > > Kever Yang (10): > rockchip: enable DEBUG_UART_BOARD_INIT by default > rockchip; kylin-rk3036: enabl DEBUG UART > rockchip: rk3036: add board_debug_uart_init() > rockchip: rk3188: add board_debug_uart_init() > rockchip: rk322x: move board_debug_uart_init() to rk322x.c > rockchip: rk3288: use grf structure to access soc_con2 > rockchip: rk3288: add board_debug_uart_init() > rockchip: rk3368: move board_debug_uart_init() to rk3368.c > rockchip: rk3399: use grf structure to access reg > rockchip: rk3399: add board_debug_uart_init() > > arch/arm/Kconfig | 2 ++ > arch/arm/mach-rockchip/Kconfig| 3 --- > arch/arm/mach-rockchip/rk3036-board-spl.c | 19 + > arch/arm/mach-rockchip/rk3036/Makefile| 1 + > arch/arm/mach-rockchip/rk3036/rk3036.c| 40 +++ > arch/arm/mach-rockchip/rk3188-board-spl.c | 12 + > arch/arm/mach-rockchip/rk3188/Makefile| 1 + > arch/arm/mach-rockchip/rk3188/rk3188.c| 37 + > arch/arm/mach-rockchip/rk322x-board-spl.c | 43 ++--- > arch/arm/mach-rockchip/rk322x-board.c | 31 + > arch/arm/mach-rockchip/rk322x/Makefile| 2 +- > arch/arm/mach-rockchip/rk322x/rk322x.c| 45 > +++ > arch/arm/mach-rockchip/rk3288-board-spl.c | 11 ++-- > arch/arm/mach-rockchip/rk3288-board-tpl.c | 13 ++--- > arch/arm/mach-rockchip/rk3288/rk3288.c| 19 +++-- > arch/arm/mach-rockchip/rk3368-board-spl.c | 5 > arch/arm/mach-rockchip/rk3368-board-tpl.c | 33 +-- > arch/arm/mach-rockchip/rk3368/rk3368.c| 31 + > arch/arm/mach-rockchip/rk3399-board-spl.c | 31 + > arch/arm/mach-rockchip/rk3399/rk3399.c| 34 ++- > configs/kylin-rk3036_defconfig| 4 +++ > 21 files changed, 223 insertions(+), 194 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3036/rk3036.c > create mode 100644 arch/arm/mach-rockchip/rk3188/rk3188.c > create mode 100644 arch/arm/mach-rockchip/rk322x/rk322x.c > > -- > 1.9.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [V6 PATCH 3/3] sunxi: Use clrsetbits_le32 instead of multiple instruction
Hi On Thu, Mar 28, 2019 at 12:08 PM Jagan Teki wrote: > > On Mon, Mar 25, 2019 at 6:17 PM Shyam Saini > wrote: > > > > From: Michael Trimarchi > > > > This will improve code readabilty > > > > Signed-off-by: Michael Trimarchi > > Signed-off-by: Shyam Saini > > --- > > Is this patch on master? couldn't apply at all? I think you should apply 1 and 2 Michael > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [V3 1/3] sunxi: Fix A33 memory initialization
Hi Philippe and Andre' On Mon, Mar 18, 2019 at 10:48 AM Shyam Saini wrote: > > From: Michael Trimarchi > > While the exact problem is not known, based on discussion between > Philipp Tomsich and André Przywara it is guessed that exit self-refresh > timing is not set with correct value. There may be implicit enter or > exit Self-Refresh anywhere as part of some training phase. > > In ZynqMP register guide [1], which is close to the various > Allwinner DRAM controllers, tXSDLL is bits [14:8], while the non-DLL > tXS is bits [6:0]: Self refresh exit delay. So it could be safely > increased and it only affects the time after the self-refresh “exit”, > which happens only after (re-)initialisation. > > There was no document for cpu in question so based on oscilloscope > readings [2][3] and observed result by comparing allwinner architecture. > So set it same as Allwinner H5 silicon. > > Before this patch, failure rate of was 7%. > > This was tested on A33 allwinner cpu, dual rank connection connected > with two MT41K512M16HA-125:A memory model. Memory is configured as DDR3 > 1.5V > Are you happy with this description? Michael > [1] https://www.xilinx.com/html_docs/registers/ug1087/ddrc___dramtmg8.html > [2] https://ibb.co/R70zmyS > [3] https://ibb.co/HVVCGQ8 > > Signed-off-by: Michael Trimarchi > Signed-off-by: Shyam Saini > --- > Changelogs: >V1->V2: adjust commit message >V2->V3: Adjust commit message based on V2 Discussion > --- > arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c > b/arch/arm/mach-sunxi/dram_sun8i_a33.c > index 1da2727f9874..5da01922bfaf 100644 > --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c > +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c > @@ -152,7 +152,7 @@ static void auto_set_timing_para(struct dram_para *para) > reg_val &= ~(0xff << 8); > reg_val &= ~(0xff << 0); > reg_val |= (0x33 << 8); > - reg_val |= (0x8 << 0); > + reg_val |= (0x10 << 0); > writel(reg_val, &mctl_ctl->dramtmg8); > /* Set phy interface time */ > reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) > -- > 2.11.0 > -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [V3 1/3] sunxi: Fix A33 memory initialization
On Mon, Mar 18, 2019 at 3:20 PM Shyam Saini wrote: > > From: Michael Trimarchi > > While the exact problem is not known, based on discussion between > Philipp Tomsich and André Przywara it is guessed that exit self-refresh > timing is not set with correct value. There may be implicit enter or > exit Self-Refresh anywhere as part of some training phase. > > In ZynqMP register guide [1], which is close to the various > Allwinner DRAM controllers, tXSDLL is bits [14:8], while the non-DLL > tXS is bits [6:0]: Self refresh exit delay. So it could be safely > increased and it only affects the time after the self-refresh “exit”, > which happens only after (re-)initialisation. > > There was no document for cpu in question so based on oscilloscope > readings [2][3] and observed result by comparing allwinner architecture. > So set it same as Allwinner H5 silicon. > > Before this patch, failure rate of was 7%. > > This was tested on A33 allwinner cpu, dual rank connection connected > with two MT41K512M16HA-125:A memory model. Memory is configured as DDR3 > 1.5V > > [1] https://www.xilinx.com/html_docs/registers/ug1087/ddrc___dramtmg8.html > [2] https://ibb.co/R70zmyS > [3] https://ibb.co/HVVCGQ8 > > Signed-off-by: Michael Trimarchi > Signed-off-by: Shyam Saini > --- > Changelogs: >V1->V2: adjust commit message >V2->V3: Adjust commit message based on V2 Discussion > --- Acked-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board/raspberrypi/rpi/MAINTAINERS
Hi Heinrich, On 28/03/2019 11:52, Heinrich Schuchardt wrote: > Hello Matthias, > > in board/raspberrypi/rpi/MAINTAINERS there is still Alex's old email > address. Are you also picking up maintainership for those files? > Yes I can do that. Shall I send a patch? Regards, Matthias > Guillaume was asking yesterday on the IRC channel. > > Cf. https://lists.denx.de/pipermail/u-boot/2019-February/358939.html > > Best regards > > Heinrich > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board/raspberrypi/rpi/MAINTAINERS
On Thu, Mar 28, 2019 at 12:45:51PM +0100, Matthias Brugger wrote: > Hi Heinrich, > > On 28/03/2019 11:52, Heinrich Schuchardt wrote: > > Hello Matthias, > > > > in board/raspberrypi/rpi/MAINTAINERS there is still Alex's old email > > address. Are you also picking up maintainership for those files? > > > > Yes I can do that. > > Shall I send a patch? Yes please, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] pico-imx7d: Add support for BL33 case
On Thu, Mar 28, 2019 at 5:30 AM Jun Nie wrote: > > Add configuration to boot U-boot as BL33 case. The boot flow > is ATF -> OPTEE -> U-boot. Could you add a README explaining how to use / test it? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] pico-imx7d: Correct uart clock root
On Thu, Mar 28, 2019 at 5:34 AM Jun Nie wrote: > > Correct uart clock root ID. Incorrect ID may result the > clock is gated because rate value 0 is returned in > imx_get_uartclk() > > Signed-off-by: Jun Nie How this could not be defined? couldn't this to be fixed on kconfig to use it as default? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: am57xx_evm: Remove ENV_IS_IN_FAT
On Thu, Mar 28, 2019 at 02:21:03PM +0530, Faiz Abbas wrote: > With U-boot supporting environment in multiple places, enable only > ENV_IS_IN_EMMC. > > Signed-off-by: Faiz Abbas > --- > configs/am57xx_evm_defconfig| 1 + > configs/am57xx_hs_evm_defconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig > index 3d71020225..e4f0458d72 100644 > --- a/configs/am57xx_evm_defconfig > +++ b/configs/am57xx_evm_defconfig > @@ -35,6 +35,7 @@ CONFIG_OF_CONTROL=y > CONFIG_SPL_OF_CONTROL=y > CONFIG_DEFAULT_DEVICE_TREE="am572x-idk" > CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 > am57xx-beagle-x15-revc am572x-idk am571x-idk am574x-idk" > +# CONFIG_ENV_IS_IN_FAT is not set > CONFIG_ENV_IS_IN_MMC=y > CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y > CONFIG_DM=y Is this really a good idea for the config we use for Beagle X15? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] fastboot: Improve error reporting on 'getvar partition-{size, type}'
Currently U-Boot reports the same error message in all below cases:
[A] host> fastboot getvar partition-type
[B] host> fastboot getvar partition-size
[C] host> fastboot getvar partition-type:
[D] host> fastboot getvar partition-size:
[E] host> fastboot getvar partition-type:
[F] host> fastboot getvar partition-size:
The message looks like:
host> fastboot getvar partition-size:
getvar:partition-size: FAILED (remote: partition not found)
Finished. Total time: 0.003s
Be more user friendly and output:
- "partition not given" for [A-D]
- "partition not found" for [E-F]
Fixes: f73a7df984a9 ("net: fastboot: Merge AOSP UDP fastboot")
Signed-off-by: Eugeniu Rosca
---
v2:
- Link v1: https://patchwork.ozlabs.org/patch/1058755/
- Benefit from the existing error strings rather than bloating the
code with new ones.
---
drivers/fastboot/fb_mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 4c1c7fd2cd8d..d04d8a448ccf 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -308,8 +308,8 @@ int fastboot_mmc_get_part_info(char *part_name, struct
blk_desc **dev_desc,
fastboot_fail("block device not found", response);
return -ENOENT;
}
- if (!part_name) {
- fastboot_fail("partition not found", response);
+ if (!part_name || !strcmp(part_name, "")) {
+ fastboot_fail("partition not given", response);
return -ENOENT;
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fastboot: getvar_partition_{type, size}: Sanitize arguments
Superseded by https://patchwork.ozlabs.org/patch/1068195/ ("[U-Boot,v2]
fastboot: Improve error reporting on 'getvar partition-{size, type}'")
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] RPi: Add mbrugger as board maintainer
From: Matthias Brugger
I took over maintainership from Alex Graf with commit
3157bbfa18 ("rpi: Make Matthias maintainer")
But I forgot to update the board maintainer file.
This patch adds myself to the game.
Signed-off-by: Matthias Brugger
---
board/raspberrypi/rpi/MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi/MAINTAINERS
b/board/raspberrypi/rpi/MAINTAINERS
index cce1a7ad76..4f1b23efc8 100644
--- a/board/raspberrypi/rpi/MAINTAINERS
+++ b/board/raspberrypi/rpi/MAINTAINERS
@@ -1,5 +1,5 @@
RPI BOARD
-M: Alexander Graf
+M: Matthias Brugger
S: Maintained
F: board/raspberrypi/rpi/
F: include/configs/rpi.h
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] RPi: Add mbrugger as board maintainer
On 3/28/19 2:47 PM, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> I took over maintainership from Alex Graf with commit
> 3157bbfa18 ("rpi: Make Matthias maintainer")
> But I forgot to update the board maintainer file.
> This patch adds myself to the game.
>
> Signed-off-by: Matthias Brugger
Reviewed-by: Heinrich Schuchardt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] toradex: common: unify behaviour when config block is missing
Reviewed-by: Igor Opaniuk
On Mon, Mar 25, 2019 at 6:19 PM Marcel Ziswiler wrote:
>
> From: Bhuvanchandra DV
>
> If the config block is missing, various things may fail or behave
> strangely on certain modules. This patch unifies that behaviour by
> using a fake MAC address, until user updates the config block.
>
> Signed-off-by: Bhuvanchandra DV
> Acked-by: Marcel Ziswiler
>
> ---
>
> Changes in v2:
> - Introduced a define for the Toradex OUI ("0x00142dUL") as suggested by
> Igor.
> - Removed redundant comment as suggested by Igor.
>
> board/toradex/common/tdx-common.c | 34 ---
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/board/toradex/common/tdx-common.c
> b/board/toradex/common/tdx-common.c
> index fde230c955..2d560cceaf 100644
> --- a/board/toradex/common/tdx-common.c
> +++ b/board/toradex/common/tdx-common.c
> @@ -12,6 +12,8 @@
> #include
> #include "tdx-common.h"
>
> +#define TORADEX_OUI 0x00142dUL
> +
> #ifdef CONFIG_TDX_CFG_BLOCK
> static char tdx_serial_str[9];
> static char tdx_board_rev_str[6];
> @@ -68,20 +70,25 @@ int show_board_info(void)
> unsigned char ethaddr[6];
>
> if (read_tdx_cfg_block()) {
> - printf("Missing Toradex config block\n");
> + printf("MISSING TORADEX CONFIG BLOCK\n");
> + tdx_eth_addr.oui = htonl(TORADEX_OUI << 8);
> + tdx_eth_addr.nic = htonl(tdx_serial << 8);
> checkboard();
> - return 0;
> + } else {
> + sprintf(tdx_serial_str, "%08u", tdx_serial);
> + sprintf(tdx_board_rev_str, "V%1d.%1d%c",
> + tdx_hw_tag.ver_major,
> + tdx_hw_tag.ver_minor,
> + (char)tdx_hw_tag.ver_assembly + 'A');
> +
> + env_set("serial#", tdx_serial_str);
> +
> + printf("Model: Toradex %s %s, Serial# %s\n",
> + toradex_modules[tdx_hw_tag.prodid],
> + tdx_board_rev_str,
> + tdx_serial_str);
> }
>
> - /* board serial-number */
> - sprintf(tdx_serial_str, "%08u", tdx_serial);
> - sprintf(tdx_board_rev_str, "V%1d.%1d%c",
> - tdx_hw_tag.ver_major,
> - tdx_hw_tag.ver_minor,
> - (char)tdx_hw_tag.ver_assembly + 'A');
> -
> - env_set("serial#", tdx_serial_str);
> -
> /*
> * Check if environment contains a valid MAC address,
> * set the one from config block if not
> @@ -101,11 +108,6 @@ int show_board_info(void)
> }
> #endif
>
> - printf("Model: Toradex %s %s, Serial# %s\n",
> - toradex_modules[tdx_hw_tag.prodid],
> - tdx_board_rev_str,
> - tdx_serial_str);
> -
> return 0;
> }
>
> --
> 2.20.1
>
> ___
> 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] RPi: Add mbrugger as board maintainer
> Am 28.03.2019 um 21:47 schrieb matthias@kernel.org:
>
> From: Matthias Brugger
>
> I took over maintainership from Alex Graf with commit
> 3157bbfa18 ("rpi: Make Matthias maintainer")
> But I forgot to update the board maintainer file.
> This patch adds myself to the game.
>
> Signed-off-by: Matthias Brugger
Reviewed-by: Alexander Graf
Alex
>
> ---
>
> board/raspberrypi/rpi/MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/raspberrypi/rpi/MAINTAINERS
> b/board/raspberrypi/rpi/MAINTAINERS
> index cce1a7ad76..4f1b23efc8 100644
> --- a/board/raspberrypi/rpi/MAINTAINERS
> +++ b/board/raspberrypi/rpi/MAINTAINERS
> @@ -1,5 +1,5 @@
> RPI BOARD
> -M:Alexander Graf
> +M:Matthias Brugger
> S:Maintained
> F:board/raspberrypi/rpi/
> F:include/configs/rpi.h
> --
> 2.20.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CONFIG_OF_EMBED
On Fri, 2019-03-22 at 10:11 +0800, Simon Glass wrote: > Hi, > > On Fri, 22 Mar 2019 at 05:37, Marek Vasut wrote: > > On 3/21/19 5:37 PM, Dalon L Westergreen wrote: > > > On Thu, 2019-03-21 at 16:48 +0100, Marek Vasut wrote: > > > > On 3/21/19 3:33 PM, Dalon L Westergreen wrote: > > > > > On Thu, 2019-03-21 at 03:30 +0100, Marek Vasut wrote: > > > > > > On 3/20/19 9:24 PM, Dalon L Westergreen wrote: > > > > > > > On Wed, 2019-03-20 at 19:37 +0100, Marek Vasut wrote: > > > > > > > > On 3/20/19 6:28 PM, Dalon L Westergreen wrote: > > > > > > > > > Hey Marek, > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > A while ago, when adding the hex output required for > > > > > > > > > stratix10, I > > > > > > > > > enabled > > > > > > > > > CONFIG_OF_EMBED so that the spl elf included the dtb. This > > > > > > > > > avoided > > > > > > > > > the > > > > > > > > > -- > > > > > > > > > change-address option when using objcopy to convert the u- > > > > > > > > > boot-spl- > > > > > > > > > dtb.bin > > > > > > > > > into > > > > > > > > > a hex file with the correct address as required by the quartus > > > > > > > > > tools. > > > > > > > > > > > > > > > > > > In any case, there is now a warning that CONFIG_OF_EMBED > > > > > > > > > should only > > > > > > > > > be > > > > > > > > > used > > > > > > > > > for > > > > > > > > > development and debug. I am wondering how best to resolve > > > > > > > > > this > > > > > > > > > issue, > > > > > > > > > should i > > > > > > > > > revert back to using objcopy with the u-boot-spl-dtb.bin, is > > > > > > > > > there a > > > > > > > > > way > > > > > > > > > to > > > > > > > > > have > > > > > > > > > CONFIG_OF_EMBED only apply to SPL? > > > > > > > > > > > > > > > > CONFIG_OF_SEPARATE is what you want. > > > > > > > > > > > > > > I dont think this is what i want exactly. I was thinking of this. > > > > > > > From 82c1d1bc6092ce40f33a04f2bc7713b0143e30a5 Mon Sep 17 00:00:00 > > > > > > > 2001 > > > > > > > From: Dalon Westergreen > > > > > > > Date: Wed, 20 Mar 2019 11:21:20 -0700 > > > > > > > Subject: [PATCH 1/2] Makefile: Add target to generate hex output > > > > > > > for > > > > > > > combined > > > > > > > spl and dtb > > > > > > > > > > > > > > Some architectures, Stratix10, require a hex formatted spl that > > > > > > > combines > > > > > > > the spl image and dtb. This adds a target to create said hex file > > > > > > > with > > > > > > > and offset of SPL_TEXT_BASE. > > I don't really follow this thread, but you should not use > CONFIG_OF_EMBED. If there is a problem with setting up the image with > CONFIG_OF_SEPARATE, we should discuss it. > > - Simon Simon, Did you see my patches following this email? They resolve the issues with S10 around CONFIG_OF_EMBED. --dalon > > > > > > > The CONFIG_OF_SEPARATE doesn't generate a combined image anymore ? > > > > > > Seems > > > > > > like it does at least on the renesas platforms (cfr e.g. > > > > > > stout_defconfig, where I use exactly that). > > > > > > > > > > It generates a combined binary, u-boot-spl-dtb.bin, as far as i know. > > > > > The elf is not combined, so using objcopy on the elf results in a hex > > > > > file without the dtb. Stratix 10 needs a combined hex file that > > > > > starts > > > > > at CONFIG_SPL_TEXT_BASE. This file is then combined by quartus with > > > > > the fpga image. The SDM loads the spl image into the cpu's onchip ram > > > > > and releases it from reset. > > > > > > > > > > So what i am trying to do is get a hex file generated that is > > > > > appriopriate > > > > > for the quartus tools. With CONFIG_OF_EMBED, this was easy, as you > > > > > just > > > > > run objcopy on the elf to create the hex output. With > > > > > CONFIG_OF_SEPARATE > > > > > you need the combined binary to do the same. hence, > > > > > > > > > > +OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex --change- > > > > > > > address=$(CONFIG_SPL_TEXT_BASE) > > > > > > > + > > > > > > > +spl/u-boot-spl-dtb.hex: spl/u-boot-spl-dtb.bin FORCE > > > > > > > + $(call if_changed,objcopy) > > > > Aha, right. CCing Simon, maybe he has some better idea. > > > > > > > > Otherwise, let's add the custom target. Maybe we can add it to > > > > arch/arm/mach-socfpga instead though. > > > > > > After a quick test to add the target to mach-socfpga instead of the root > > > Makefile, it seems i would still need to modify the root Makefile to call > > > the mach-socfpga makefile for the target in any case. If acceptable, i > > > think it cleaner to just add the target to the root Makefile. > > > > I think that's fine. The root Makefile is growing like dough. that needs > > to stop. > > > > -- > > Best regards, > > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND RFC PATCH v1] MLK-12883 usb: limit USB_MAX_XFER_BLK to 256
There is a typo in the comment: USB Massstorage
Also regarding refering to a specific commit ("(cherry picked from
commit df0052575b2bc9d66ae73584768e1a457ed5d914)" line):
> If you want to refer to a specific commit, don’t just refer to the SHA-1 ID
> of the commit.
> Please also include the oneline summary of the commit, to make it easier for
> reviewers to know what it is about. Example:
> Commit e21d2170f36602ae2708 ("video: remove unnecessary
> platform_set_drvdata()")
[1]: https://www.kernel.org/doc/html/v5.1-rc2/process/submitting-patches.html
On Mon, Mar 25, 2019 at 6:20 PM Marcel Ziswiler wrote:
>
> From: Peng Fan
>
> For Some USB mass storage devices, such as:
> "
> - Kingston DataTraveler 2.0 001D7D06CF09B04199C7B3EA
> - Class: (from Interface) Mass Storage
> - PacketSize: 64 Configurations: 1
> - Vendor: 0x0930 Product 0x6545 Version 1.16
> "
> When `usb read 0x8000 0 0x2000`, we met
> "EHCI timed out on TD - token=0x80008d80".
>
> The devices does not support scsi VPD page, we are not able
> to get the maximum transfer length for READ(10)/WRITE(10).
>
> So we limit this to 256 blocks as READ(6).
>
> Signed-off-by: Peng Fan
> Acked-by: Marcel Ziswiler
> (cherry picked from commit df0052575b2bc9d66ae73584768e1a457ed5d914)
>
> ---
> This comes from NXP's downstream and has proven to tremendously improve
> the situation with those odd USB mass storage aka memory sticks. This is
> why I post it here asking whether or not this may be something
> benefiting more people. Any feedback and suggestions are welcome.
>
> common/usb_storage.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/common/usb_storage.c b/common/usb_storage.c
> index 8c889bb1a6..7420438363 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -949,7 +949,11 @@ static void usb_stor_set_max_xfer_blk(struct usb_device
> *udev,
> * there is enough free heap space left, but the SCSI READ(10) and
> * WRITE(10) commands are limited to 65535 blocks.
> */
> - blk = USHRT_MAX;
> + /*
> +* Some USB Massstorage devices have issues, limiting this to 256
> +* fixes this.
> +*/
> + blk = 256;
> #else
> blk = 20;
> #endif
> --
> 2.20.1
>
> ___
> 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] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL
On 25. 03. 19 9:08, Michal Simek wrote: > On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote: >> >> The purpose of this series is to provide the SPL with ability to apply >> overlays for u-boot. this is only a RFC so far, to get a feedback on the >> approach. >> >> Our use-case is the support of the daughter boards of the AM65x EVM. In >> Linux, each board is supported by a unique overlay. The presence of the >> boards is detected at runtime, and some useful features (like USB) are >> implemented on those daughter boards. Instead of providing multiple dtbs >> and fall in a combinatorial pit, we propose to use DT overlays. > > Not sure if you have it on these boards too but I expect you are able to > detect base board with this code board/ti/common/board_detect.c > > How do you detect these daughter cards? Is there additional I2C > connection to them and they have on board eeprom with any format for > detection? > Something similar what it is part of FMC standard/VITA 57.1 with using > FRU spec for daughter card description? > Anyway we are working on FRU parser exactly for this purpose. > > Do you also need to apply that overlays in SPL? > Isn't it enough to apply them as the part of board_fdt_blob_setup()? I see v2 now but without answering my questions here. M ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 00/12] Add support for applications of overlays in SPL
On 27. 03. 19 16:38, Jean-Jacques Hiblot wrote: > > The purpose of this series is to provide the SPL with ability to apply > overlays for u-boot. this is only a RFC so far, to get a feedback on the > approach. > > Our use-case is the support of the daughter boards of the AM65x EVM. In > Linux, each board is supported by a unique overlay. The presence of the > boards is detected at runtime, and some useful features (like USB) are > implemented on those daughter boards. Instead of providing multiple dtbs > and fall in a combinatorial pit, we propose to use DT overlays. > > Patch #1 "spl: fit: Add support for applying DT overlay" has been posted > a few weeks ago by Michal Simek. > Patch #2 and #3 amend Michal's patch. > Patch #4 and #5 are simple fixes for the Makefile > Patch #6 is not required but relates to this series and will be required > later by the AM6x platform > Patch #7 may be a bit controversial. It basically replaces u-boot.img with > a symlink to u-boot.itb in case we use a "complex" FIT (ie: if > SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set). This breaks buildman for > several platforms because not all the binaries embedded in the FIT are > available. > Patch #9 adds a way to dynamically select the DT overlays. That is were we > would use HW detection to select the required overlays. In that case, the > board-level code tells what overlay it needs (it gives the name of the > node). > Patch #10 disables advanced SPL FIT features to keep the size of the SPL of > the am335x_evm in check > Patch #11 is not required, but demonstrates on a DRA76-evm how this series > can be used. > > On arm, if overlay are supported, this series increases the size of the SPL > by 3-4 kB. > > Changes in v2: > - reworked board_fit_get_additionnal_images() and how it used in spl_fit.c > - removed dtbo generation from dtso files and use .dts extension for the > overlays > - add dynamic allocation usage in a separate patch > - defconfig change for the am335x_evm This series looks better. Is this able to also handle different images then just dtbs? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/22] colibri_vf: migrate fec, esdhc, nfc and usb to driver model
Reviewed-by: Igor Opaniuk
On Mon, Mar 25, 2019 at 6:30 PM Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Migrate FEC, ESDHC, NFC and USB to driver model.
>
> While at it also do no longer enable optional I2C clock in board file as
> the generic clock code now handles this. Note for space reason and as
> it is not required just for booting we do not enable I2C in U-Boot by
> default.
>
> While at it also update copyright period.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> Changes in v2: None
>
> board/toradex/colibri_vf/colibri_vf.c | 82 +--
> configs/colibri_vf_defconfig | 5 ++
> include/configs/colibri_vf.h | 13 +
> 3 files changed, 7 insertions(+), 93 deletions(-)
>
> diff --git a/board/toradex/colibri_vf/colibri_vf.c
> b/board/toradex/colibri_vf/colibri_vf.c
> index 8e0dea2dc2..c4d05532fe 100644
> --- a/board/toradex/colibri_vf/colibri_vf.c
> +++ b/board/toradex/colibri_vf/colibri_vf.c
> @@ -16,23 +16,16 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> -#include
> #include
> -#include
> -#include
> #include
> -#include
> #include
>
> #include "../common/tdx-common.h"
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -#define USB_PEN_GPIO 83
> -#define USB_CDET_GPIO 102
> #define PTC0_GPIO_45 45
>
> static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
> @@ -239,25 +232,6 @@ static void setup_tcon(void)
> }
> #endif
>
> -#ifdef CONFIG_FSL_ESDHC
> -struct fsl_esdhc_cfg esdhc_cfg[1] = {
> - {ESDHC1_BASE_ADDR},
> -};
> -
> -int board_mmc_getcd(struct mmc *mmc)
> -{
> - /* eSDHC1 is always present */
> - return 1;
> -}
> -
> -int board_mmc_init(bd_t *bis)
> -{
> - esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
> -
> - return fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
> -}
> -#endif
> -
> static inline int is_colibri_vf61(void)
> {
> struct mscm *mscm = (struct mscm *)MSCM_BASE_ADDR;
> @@ -290,7 +264,7 @@ static void clock_init(void)
> CCM_CCGR3_ANADIG_CTRL_MASK |
> CCM_CCGR3_SCSC_CTRL_MASK);
> clrsetbits_le32(&ccm->ccgr4, CCM_REG_CTRL_MASK,
> CCM_CCGR4_WKUP_CTRL_MASK | CCM_CCGR4_CCM_CTRL_MASK |
> - CCM_CCGR4_GPC_CTRL_MASK | CCM_CCGR4_I2C0_CTRL_MASK);
> + CCM_CCGR4_GPC_CTRL_MASK);
> clrsetbits_le32(&ccm->ccgr6, CCM_REG_CTRL_MASK,
> CCM_CCGR6_OCOTP_CTRL_MASK |
> CCM_CCGR6_DDRMC_CTRL_MASK);
> clrsetbits_le32(&ccm->ccgr7, CCM_REG_CTRL_MASK,
> @@ -379,14 +353,6 @@ static void mscm_init(void)
> writew(MSCM_IRSPRC_CP0_EN, &mscmir->irsprc[i]);
> }
>
> -int board_phy_config(struct phy_device *phydev)
> -{
> - if (phydev->drv->config)
> - phydev->drv->config(phydev);
> -
> - return 0;
> -}
> -
> int board_early_init_f(void)
> {
> clock_init();
> @@ -433,13 +399,8 @@ int board_init(void)
> * so we must use the external oscillator in order
> * to maintain correct time in the hwclock
> */
> -
> setbits_le32(&scsc->sosc_ctr, SCSC_SOSC_CTR_SOSC_EN);
>
> -#ifdef CONFIG_USB_EHCI_VF
> - gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
> -#endif
> -
> return 0;
> }
>
> @@ -476,47 +437,6 @@ int ft_board_setup(void *blob, bd_t *bd)
> }
> #endif
>
> -#ifdef CONFIG_USB_EHCI_VF
> -int board_ehci_hcd_init(int port)
> -{
> - switch (port) {
> - case 0:
> - /* USBC does not have PEN, also configured as USB client only
> */
> - break;
> - case 1:
> - gpio_request(USB_PEN_GPIO, "usb-pen-gpio");
> - gpio_direction_output(USB_PEN_GPIO, 0);
> - break;
> - }
> - return 0;
> -}
> -
> -int board_usb_phy_mode(int port)
> -{
> - switch (port) {
> - case 0:
> - /*
> -* Port 0 is used only in client mode on Colibri Vybrid
> modules
> -* Check for state of USB client gpio pin and accordingly
> return
> -* USB_INIT_DEVICE or USB_INIT_HOST.
> -*/
> - if (gpio_get_value(USB_CDET_GPIO))
> - return USB_INIT_DEVICE;
> - else
> - return USB_INIT_HOST;
> - case 1:
> - /* Port 1 is used only in host mode on Colibri Vybrid modules
> */
> - return USB_INIT_HOST;
> - default:
> - /*
> -* There are only two USB controllers on Vybrid. Ideally we
> will
> -* not reach here. However return USB_INIT_HOST if we do.
> -*/
> - return USB_INIT_HOST;
> - }
> -}
> -#endif
> -
> /*
> * Backlight off before OS handover
> */
> diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
> index 9a91cb4b82..344fe77234 100644
> --- a/configs/colibri_vf_defconfi
Re: [U-Boot] [PATCH v2 13/22] colibri_vf: add distroboot support
Hi Marcel,
Reviewed-by: Igor Opaniuk
Please check some minor comments below (could be addressed in a
separate patchset):
On Mon, Mar 25, 2019 at 6:35 PM Marcel Ziswiler wrote:
>
> From: Stefan Agner
>
> Add support for distro boot. This is especially helpful for external
> devices. There is a global boot command which scans a predefined
> list of boot targets:
> run distro_bootcmd
>
> As well as direct boot commands such as:
> run bootcmd_mmc0
> run bootcmd_usb
> run bootcmd_dhcp
> ...
>
> Refer to doc/README.distro fo details.
>
> While at it also re-order boot command macros as well as the
> CONFIG_EXTRA_ENV_SETTINGS.
>
> Signed-off-by: Stefan Agner
> Acked-by: Max Krummenacher
> Acked-by: Marcel Ziswiler
>
> ---
>
> Changes in v2: None
>
> include/configs/colibri_vf.h | 75 ++--
> 1 file changed, 46 insertions(+), 29 deletions(-)
>
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index 9effa56539..83a33ff786 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -48,13 +48,15 @@
> /* We boot from the gfxRAM area of the OCRAM. */
> #define CONFIG_BOARD_SIZE_LIMIT520192
>
> -#define SD_BOOTCMD \
> - "sdargs=root=/dev/mmcblk0p2 rw rootwait\0" \
minor: "mmcblk0p2" (it's used in multiple places) can also be put into
the separate variable in case if we decide to change the partition
layout in the future.
> - "sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${mtdparts} "
> \
> - "${setupargs} ${vidargs}; echo Booting from MMC/SD card...; " \
> - "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
> - "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-${fdt_board}.dtb &&
> " \
minor: I think we should unify (can be addressed in another patchset)
the way how dtb names are concatenated (and for example use this
scheme for all Toradex SoMs; particularly for Colibri iMX6DL the
full-name is still hardcoded "imx6dl-colibri-eval-v3.dtb")
> - "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
> +#define MEM_LAYOUT_ENV_SETTINGS \
> + "bootm_size=0x1000\0" \
> + "fdt_addr_r=0x8200\0" \
> + "fdt_high=0x\0" \
> + "initrd_high=0x\0" \
> + "kernel_addr_r=0x8100\0" \
> + "pxefile_addr_r=0x8710\0" \
> + "ramdisk_addr_r=0x8210\0" \
> + "scriptaddr=0x8700\0"
>
> #define NFS_BOOTCMD \
> "nfsargs=ip=:eth0: root=/dev/nfs\0" \
> @@ -65,7 +67,15 @@
> "tftp ${fdt_addr_r} ${soc}-colibri-${fdt_board}.dtb && " \
> "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
>
> -#define UBI_BOOTCMD\
> +#define SD_BOOTCMD \
> + "sdargs=root=/dev/mmcblk0p2 rw rootwait\0" \
> + "sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${mtdparts} "
> \
> + "${setupargs} ${vidargs}; echo Booting from MMC/SD card...; " \
> + "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
> + "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-${fdt_board}.dtb &&
> " \
> + "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
> +
> +#define UBI_BOOTCMD \
> "ubiargs=ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs " \
> "ubi.fm_autoconvert=1\0" \
> "ubiboot=run setup; " \
> @@ -76,36 +86,43 @@
> "ubi read ${fdt_addr_r} dtb && " \
> "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
>
> -#define CONFIG_BOOTCOMMAND "run ubiboot; run sdboot; run nfsboot"
> +#define CONFIG_BOOTCOMMAND "run ubiboot; run distro_bootcmd;"
> +
> +#define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 0) \
> + func(USB, usb, 0) \
> + func(DHCP, dhcp, na)
> +#include
> +#undef BOOTENV_RUN_NET_USB_START
> +#define BOOTENV_RUN_NET_USB_START ""
>
> #define DFU_ALT_NAND_INFO "vf-bcb part 0,1;u-boot part 0,2;ubi part 0,4"
>
> #define CONFIG_EXTRA_ENV_SETTINGS \
> - "kernel_addr_r=0x8200\0" \
> - "fdt_addr_r=0x8400\0" \
> - "kernel_file=zImage\0" \
> - "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
> + BOOTENV \
> + MEM_LAYOUT_ENV_SETTINGS \
> + NFS_BOOTCMD \
> + SD_BOOTCMD \
> + UBI_BOOTCMD \
> + "console=ttyLP0\0" \
> + "defargs=\0" \
> + "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
> "fdt_board=eval-v3\0" \
> + "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
> "fdt_fixup=;\0" \
> - "defargs=\0" \
> - "console=ttyLP0\0" \
> - "setup=setenv setupargs " \
> - "console=tty1 console=${console}" \
> - ",${baudrate}n8 ${memargs}\0" \
> + "kernel_file=zImage\0" \
> + "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> "setsdupdate=mmc rescan && set interface mmc && " \
> - "fatload ${interface} 0:1 ${loadaddr} flash_blk.img && " \
> - "source ${loadaddr}\0" \
> - "setusbupdate=usb start && set interface us
Re: [U-Boot] [PATCH v2 14/22] colibri_vf: set fdtfile for distroboot
Reviewed-by: Igor Opaniuk
On Mon, Mar 25, 2019 at 6:32 PM Marcel Ziswiler wrote:
>
> From: Stefan Agner
>
> Set fdtfile to represent the current board. This allows distribution
> to load the correct device tree, which in the module case often
> deviates from the common fallback ${soc}-${board}${boardver}.dtb...
>
> Signed-off-by: Stefan Agner
> Acked-by: Max Krummenacher
> Acked-by: Marcel Ziswiler
>
> ---
>
> Changes in v2: None
>
> include/configs/colibri_vf.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index 83a33ff786..0bbeeb902e 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -86,7 +86,8 @@
> "ubi read ${fdt_addr_r} dtb && " \
> "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
>
> -#define CONFIG_BOOTCOMMAND "run ubiboot; run distro_bootcmd;"
> +#define CONFIG_BOOTCOMMAND "run ubiboot; " \
> + "setenv fdtfile ${soc}-colibri-${fdt_board}.dtb && run
> distro_bootcmd;"
>
> #define BOOT_TARGET_DEVICES(func) \
> func(MMC, mmc, 0) \
> @@ -108,7 +109,6 @@
> "defargs=\0" \
> "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
> "fdt_board=eval-v3\0" \
> - "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
> "fdt_fixup=;\0" \
> "kernel_file=zImage\0" \
> "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> --
> 2.20.1
>
> ___
> 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 10/22] colibri_vf: migrate pinctrl and regulators to dtb/dm
Reviewed-by: Igor Opaniuk
On Mon, Mar 25, 2019 at 6:30 PM Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Migrate pinctrl and regulators to device tree resp. driver model: DDR,
> DSPI, ENET, ESDHC, I2C, NFC and UART.
>
> Enable CMD_DM, PINCTRL and DM_REGULATOR.
>
> While at it also update copyright period and sort include files.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> Changes in v2: None
>
> board/toradex/colibri_vf/colibri_vf.c | 139 ++
> configs/colibri_vf_defconfig | 5 +
> 2 files changed, 16 insertions(+), 128 deletions(-)
>
> diff --git a/board/toradex/colibri_vf/colibri_vf.c
> b/board/toradex/colibri_vf/colibri_vf.c
> index 79f702f2bf..8e0dea2dc2 100644
> --- a/board/toradex/colibri_vf/colibri_vf.c
> +++ b/board/toradex/colibri_vf/colibri_vf.c
> @@ -1,43 +1,36 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2015 Toradex, Inc.
> + * Copyright 2015-2019 Toradex, Inc.
> *
> * Based on vf610twr.c:
> * Copyright 2013 Freescale Semiconductor, Inc.
> */
>
> #include
> -#include
> +
> +#include
> +#include
> +#include
> #include
> #include
> -#include
> -#include
> -#include
> -#include
> +#include
> +#include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
> -#include
> -#include
> -#include
> #include
> +
> #include "../common/tdx-common.h"
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
> - PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
> -
> -#define ESDHC_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_HIGH | \
> - PAD_CTL_DSE_20ohm | PAD_CTL_OBE_IBE_ENABLE)
> -
> -#define ENET_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
> - PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> -
> #define USB_PEN_GPIO 83
> #define USB_CDET_GPIO 102
> #define PTC0_GPIO_45 45
> @@ -89,11 +82,6 @@ static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
> { 0, -1 }
> };
>
> -static const iomux_v3_cfg_t usb_pads[] = {
> - VF610_PAD_PTD4__GPIO_83,
> - VF610_PAD_PTC29__GPIO_102,
> -};
> -
> int dram_init(void)
> {
> static const struct ddr3_jedec_timings timings = {
> @@ -147,92 +135,12 @@ int dram_init(void)
> .wldqsen = 25,
> };
>
> - ddrmc_setup_iomux(NULL, 0);
> -
> ddrmc_ctrl_init_ddr3(&timings, colibri_vf_cr_settings, NULL, 1, 2);
> gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
>
> return 0;
> }
>
> -static void setup_iomux_uart(void)
> -{
> - static const iomux_v3_cfg_t uart_pads[] = {
> - NEW_PAD_CTRL(VF610_PAD_PTB4__UART1_TX, UART_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTB5__UART1_RX, UART_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTB10__UART0_TX, UART_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTB11__UART0_RX, UART_PAD_CTRL),
> - };
> -
> - imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
> -}
> -
> -static void setup_iomux_enet(void)
> -{
> - static const iomux_v3_cfg_t enet0_pads[] = {
> - NEW_PAD_CTRL(VF610_PAD_PTA6__RMII0_CLKOUT, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC10__RMII1_MDIO, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC9__RMII1_MDC, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC11__RMII1_CRS_DV, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC12__RMII1_RD1, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC13__RMII1_RD0, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC14__RMII1_RXER, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC15__RMII1_TD1, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC16__RMII1_TD0, ENET_PAD_CTRL),
> - NEW_PAD_CTRL(VF610_PAD_PTC17__RMII1_TXEN, ENET_PAD_CTRL),
> - };
> -
> - imx_iomux_v3_setup_multiple_pads(enet0_pads, ARRAY_SIZE(enet0_pads));
> -}
> -
> -static void setup_iomux_i2c(void)
> -{
> - static const iomux_v3_cfg_t i2c0_pads[] = {
> - VF610_PAD_PTB14__I2C0_SCL,
> - VF610_PAD_PTB15__I2C0_SDA,
> - };
> -
> - imx_iomux_v3_setup_multiple_pads(i2c0_pads, ARRAY_SIZE(i2c0_pads));
> -}
> -
> -#ifdef CONFIG_NAND_VF610_NFC
> -static void setup_iomux_nfc(void)
> -{
> - static const iomux_v3_cfg_t nfc_pads[] = {
> - VF610_PAD_PTD23__NF_IO7,
> - VF610_PAD_PTD22__NF_IO6,
> - VF610_PAD_PTD21__NF_IO5,
> - VF610_PAD_PTD20__NF_IO4,
> - VF610_PAD_PTD19__NF_IO3,
> - VF610_PAD_PTD18__NF_IO2,
> - VF610_PAD_PTD17__NF_IO1,
> - VF610_PAD_PTD16__NF_IO0,
> - VF610_PAD_PTB24__NF_WE_B,
> - VF610_PAD_PTB25__NF_CE0_B,
> -
Re: [U-Boot] [PATCH v2 13/22] colibri_vf: add distroboot support
Hi Igor
On Thu, 2019-03-28 at 15:01 +, Igor Opaniuk wrote:
> Hi Marcel,
>
> Reviewed-by: Igor Opaniuk
>
> Please check some minor comments below (could be addressed in a
> separate patchset):
>
> On Mon, Mar 25, 2019 at 6:35 PM Marcel Ziswiler
> wrote:
> > From: Stefan Agner
> >
> > Add support for distro boot. This is especially helpful for
> > external
> > devices. There is a global boot command which scans a predefined
> > list of boot targets:
> > run distro_bootcmd
> >
> > As well as direct boot commands such as:
> > run bootcmd_mmc0
> > run bootcmd_usb
> > run bootcmd_dhcp
> > ...
> >
> > Refer to doc/README.distro fo details.
> >
> > While at it also re-order boot command macros as well as the
> > CONFIG_EXTRA_ENV_SETTINGS.
> >
> > Signed-off-by: Stefan Agner
> > Acked-by: Max Krummenacher
> > Acked-by: Marcel Ziswiler
> >
> > ---
> >
> > Changes in v2: None
> >
> > include/configs/colibri_vf.h | 75 ++
> > --
> > 1 file changed, 46 insertions(+), 29 deletions(-)
> >
> > diff --git a/include/configs/colibri_vf.h
> > b/include/configs/colibri_vf.h
> > index 9effa56539..83a33ff786 100644
> > --- a/include/configs/colibri_vf.h
> > +++ b/include/configs/colibri_vf.h
> > @@ -48,13 +48,15 @@
> > /* We boot from the gfxRAM area of the OCRAM. */
> > #define CONFIG_BOARD_SIZE_LIMIT520192
> >
> > -#define SD_BOOTCMD \
> > - "sdargs=root=/dev/mmcblk0p2 rw rootwait\0" \
> minor: "mmcblk0p2" (it's used in multiple places) can also be put
> into
> the separate variable in case if we decide to change the partition
> layout in the future.
With BSP 3.0 we anyway plan to transition to proper distroboot.
> > - "sdboot=run setup; setenv bootargs ${defargs} ${sdargs}
> > ${mtdparts} " \
> > - "${setupargs} ${vidargs}; echo Booting from MMC/SD card...;
> > " \
> > - "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
> > - "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-
> > ${fdt_board}.dtb && " \
> minor: I think we should unify (can be addressed in another patchset)
> the way how dtb names are concatenated (and for example use this
> scheme for all Toradex SoMs; particularly for Colibri iMX6DL the
> full-name is still hardcoded "imx6dl-colibri-eval-v3.dtb")
Yeah, that is another legacy in need of cleaning up.
> > - "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0"
> > \
> > +#define MEM_LAYOUT_ENV_SETTINGS \
> > + "bootm_size=0x1000\0" \
> > + "fdt_addr_r=0x8200\0" \
> > + "fdt_high=0x\0" \
> > + "initrd_high=0x\0" \
> > + "kernel_addr_r=0x8100\0" \
> > + "pxefile_addr_r=0x8710\0" \
> > + "ramdisk_addr_r=0x8210\0" \
> > + "scriptaddr=0x8700\0"
> >
> > #define NFS_BOOTCMD \
> > "nfsargs=ip=:eth0: root=/dev/nfs\0" \
> > @@ -65,7 +67,15 @@
> > "tftp ${fdt_addr_r} ${soc}-colibri-${fdt_board}.dtb && " \
> > "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0"
> > \
> >
> > -#define UBI_BOOTCMD\
> > +#define SD_BOOTCMD \
> > + "sdargs=root=/dev/mmcblk0p2 rw rootwait\0" \
> > + "sdboot=run setup; setenv bootargs ${defargs} ${sdargs}
> > ${mtdparts} " \
> > + "${setupargs} ${vidargs}; echo Booting from MMC/SD card...;
> > " \
> > + "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
> > + "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-
> > ${fdt_board}.dtb && " \
> > + "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0"
> > \
> > +
> > +#define UBI_BOOTCMD \
> > "ubiargs=ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs " \
> > "ubi.fm_autoconvert=1\0" \
> > "ubiboot=run setup; " \
> > @@ -76,36 +86,43 @@
> > "ubi read ${fdt_addr_r} dtb && " \
> > "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0"
> > \
> >
> > -#define CONFIG_BOOTCOMMAND "run ubiboot; run sdboot; run nfsboot"
> > +#define CONFIG_BOOTCOMMAND "run ubiboot; run distro_bootcmd;"
> > +
> > +#define BOOT_TARGET_DEVICES(func) \
> > + func(MMC, mmc, 0) \
> > + func(USB, usb, 0) \
> > + func(DHCP, dhcp, na)
> > +#include
> > +#undef BOOTENV_RUN_NET_USB_START
> > +#define BOOTENV_RUN_NET_USB_START ""
> >
> > #define DFU_ALT_NAND_INFO "vf-bcb part 0,1;u-boot part 0,2;ubi
> > part 0,4"
> >
> > #define CONFIG_EXTRA_ENV_SETTINGS \
> > - "kernel_addr_r=0x8200\0" \
> > - "fdt_addr_r=0x8400\0" \
> > - "kernel_file=zImage\0" \
> > - "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
> > + BOOTENV \
> > + MEM_LAYOUT_ENV_SETTINGS \
> > + NFS_BOOTCMD \
> > + SD_BOOTCMD \
> > + UBI_BOOTCMD \
> > + "console=ttyLP0\0" \
> > + "defargs=\0" \
> > + "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
> > "fdt_board=eval-v3\0" \
> > + "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
> > "fdt_fixup=;\0" \
[U-Boot] AHCI issue on Intel Apollolake
Has anybody a hint for me? => scsi rescan Reset SCSI scanning bus for devices... ahci mmio_base=0xcf42c000 ahci_host_init: start cap 0xe536ff01 port_map 0x3 n_ports 2 SATA link ok. Spinning up device on SATA port 0... Target spinup took 0 ms. ok. PORT_SCR_ERR 0x0 PORT_IRQ_STAT 0x0 SATA port 0 status: 0x123 SATA link 1 timeout. HOST_CTL 0x8000 HOST_CTL 0x8002 AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp pio slum part apst Enter start port: 0 Port 0 status: 123 cmd_slot = 7a88c800 cmd_tbl_dma = 7a88ca00 Exit start port 0 PORT_SCR_ERR 0x0 PORT_SCR_STAT 0x123 Can not start port 0 Enter ahci_device_data_io: for port 0 ahci_dcache_flush_range: flush dcache: [0x7a88c800, 0x7a88d100) ahci_dcache_flush_range: flush dcache: [0x7a874340, 0x7a874540) timeout exit! scsi_ahci: SCSI inquiry command failure. SCSI command 0x12 ret errno -5 Enter ahci_device_data_io: for port 1 No Link on port 1! scsi_ahci: SCSI inquiry command failure. SCSI command 0x12 ret errno -5 => -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] common: Implement A/B metadata
Hello Igor, All,
On Thu, Mar 21, 2019 at 05:39:36PM +0200, Igor Opaniuk wrote:
> Hi Eugeniu,
>
> On Fri, Mar 8, 2019 at 7:29 PM Eugeniu Rosca wrote:
[..]
> >
> > The s/uint8_t/u8/ and s/uint32_t/u32/ conversion creates noise
> > comparing the in-tree versus out-of-tree files and will add some
> > overhead during integration. I still see a lot of U-Boot code saying
> > uint8_t/uint32_t, so I wonder if these can be preserved. BTW, some of
> > the patches from this series add code using uint32_t.
>
> Agree.
Igor, many thanks for the recent replies.
WRT preserving the contents of the original bootloader_message.h from
https://android.googlesource.com/platform/bootable/recovery.git/ , I
wonder what's the chance of keeping the CPP comments in place when
importing the file in-tree, since it will make the diffs and subsequent
integration/updates easier from the source repository. Furthermore, we
don't expect any U-Boot specific development to be done in this file
in-tree. It should purely reflect the upstream state.
I wonder if there is any official position regarding that from the
U-Boot maintainers?
FTR/FWIW, there are around 24 .c/.h files in U-Boot master, carrying CPP
comments (SDPX identifiers carefully excluded):
$ git grep "^\s*//\s" -- "*.c" "*.h" | grep -v "SPDX" | awk '{print $1}' | sort
-u | cut -d ':' -f 1
arch/arm/mach-tegra/board2.c
arch/riscv/include/asm/encoding.h
arch/xtensa/include/asm/arch-dc233c/tie-asm.h
arch/xtensa/include/asm/arch-de212/tie-asm.h
board/freescale/lx2160a/eth_lx2160aqds.c
board/renesas/blanche/qos.c
board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
drivers/video/stb_truetype.h
drivers/video/stb_truetype.h
fs/ubifs/ubifs.h
include/efi_api.h
include/linux/mtd/flashchip.h
include/linux/mtd/mtd.h
lib/efi_loader/efi_hii.c
lib/efi_selftest/efi_selftest_crc32.c
lib/efi_selftest/efi_selftest_hii_data.c
lib/libavb/avb_slot_verify.c
scripts/kconfig/expr.c
scripts/kconfig/gconf.c
scripts/kconfig/qconf.h
tools/mingw_support.c
>
> > Thanks and best regards,
> > Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 20/22] colibri_vf: adjust timing according to data sheet
Reviewed-by: Igor Opaniuk On Mon, Mar 25, 2019 at 6:32 PM Marcel Ziswiler wrote: > > From: Stefan Agner > > Using the DDR Validation tool in Processor Expert uncovered two > timing inconsistencies. Since those timings are related to the > suspend mode they do not affect or change regular memory behaviour. > > Signed-off-by: Stefan Agner > Acked-by: Marcel Ziswiler > > --- > > Changes in v2: None > > board/toradex/colibri_vf/colibri_vf.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/board/toradex/colibri_vf/colibri_vf.c > b/board/toradex/colibri_vf/colibri_vf.c > index 9c5bf4951b..3e39912f91 100644 > --- a/board/toradex/colibri_vf/colibri_vf.c > +++ b/board/toradex/colibri_vf/colibri_vf.c > @@ -101,15 +101,21 @@ int dram_init(void) > .tras_lockout = 0, > .tdal = 12, > .bstlen= 3, > - .tdll = 512, > + .tdll = 512, /* not applicable since freq. > scaling > + * is not used > + */ > .trp_ab= 6, > .tref = 3120, > .trfc = 64, > .tref_int = 0, > .tpdex = 3, > .txpdll= 10, > - .txsnr = 48, > - .txsr = 468, > + .txsnr = 68, /* changed to conform to JEDEC > + * specifications > + */ > + .txsr = 506, /* changed to conform to JEDEC > + * specifications > + */ > .cksrx = 5, > .cksre = 5, > .freq_chg_en = 0, > -- > 2.20.1 > > ___ > 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] sunxi: video: HDMI: Fix clock setup
Dne četrtek, 28. marec 2019 ob 08:52:48 CET je Jagan Teki napisal(a):
> On Sun, Mar 24, 2019 at 11:56 PM Jernej Skrabec
wrote:
> > Currently, HDMI driver doesn't consider minimum and maximum allowed rate
> > of pll3 (video PLL). It works most of the time, but not always.
> >
> > Consider monitor with resolution 1920x1200, which has pixel clock rate
> > of 154 MHz. Current code would determine that pll3 rate has to be set to
> > 154 MHz. However, minimum supported rate is 192 MHz. In this case video
> > output just won't work.
>
> I set the monitor with same resolution, but not sure with the pixel
> clock and unable to reproduce this with couple time. any specific
> usage case that the issue will reproduce ?
Just enable debug output in sunxi_dw_hdmi.c and clock parameters should be
displayed during boot (dotclock == pixel clock).
While I don't have such monitor, I got report about non working video output
on such monitor. This patch solved it.
Issue is most apparent when pixel clock is between 148.5 MHz and 192 MHz. Even
then, it might work sometimes or unstable. I can tell you that I managed to
have stable output even when PLL3 was set to 128 MHz, but only if correct PLL
factors were used. If I set different ones (with same output frequency), it
didn't work. I imagine it might also depend on a chip batch. Some chips may
better handle lower rates than others.
At the end, I think there is a reason why Allwinner provided clock driver
doesn't use frequencies below 192 MHz.
>
> > The reason why the driver is written in the way it is, is that at the
> > time HDMI PHY and clock configuration wasn't fully understood. But now
> > we have needed knowledge, so the issue can be fixed.
> >
> > With this fix, clock configuration routine uses full range (1-16) for
> > clock divider instead of limited one (1, 2, 4, 11). It also considers
> > minimum and maximum allowed rate for pll3.
> >
> > Fixes: 56009451d843 ("sunxi: video: Add A64/H3/H5 HDMI driver")
> > Signed-off-by: Jernej Skrabec
> > ---
> > Hi!
> >
> > Unfortunately, issue fixed with patch here has influence on Linux too.
> > In Linux, minimum and maximum rate is considered only when changing rate.
> > But because U-Boot already set PLL to "correct" value, Linux clock driver
> > doesn't see the need to change it. I know that this is Linux driver issue
> > but let's start at the source of the issue and fix it.
> >
> > It would be very nice if this can go in 2019.04 release.
> >
> > Best regards,
> > Jernej
> >
> > drivers/video/sunxi/sunxi_dw_hdmi.c | 62 +
> > 1 file changed, 37 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
> > b/drivers/video/sunxi/sunxi_dw_hdmi.c index 9dbea649a0..6fe1aa7ee4 100644
> > --- a/drivers/video/sunxi/sunxi_dw_hdmi.c
> > +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
> > @@ -132,7 +132,7 @@ static int sunxi_dw_hdmi_wait_for_hpd(void)
> >
> > return -1;
> >
> > }
> >
> > -static void sunxi_dw_hdmi_phy_set(uint clock)
> > +static void sunxi_dw_hdmi_phy_set(uint clock, int phy_div)
> >
> > {
> >
> > struct sunxi_hdmi_phy * const phy =
> >
> > (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE +
> > HDMI_PHY_OFFS);
> >
> > @@ -146,7 +146,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> >
> > switch (div) {
> >
> > case 1:
> > writel(0x30dc5fc0, &phy->pll);
> >
> > - writel(0x800863C0, &phy->clk);
> > + writel(0x800863C0 | (phy_div - 1), &phy->clk);
> >
> > mdelay(10);
> > writel(0x0001, &phy->unk3);
> > setbits_le32(&phy->pll, BIT(25));
> >
> > @@ -164,7 +164,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> >
> > break;
> >
> > case 2:
> > writel(0x39dc5040, &phy->pll);
> >
> > - writel(0x80084381, &phy->clk);
> > + writel(0x80084380 | (phy_div - 1), &phy->clk);
> >
> > mdelay(10);
> > writel(0x0001, &phy->unk3);
> > setbits_le32(&phy->pll, BIT(25));
> >
> > @@ -178,7 +178,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> >
> > break;
> >
> > case 4:
> > writel(0x39dc5040, &phy->pll);
> >
> > - writel(0x80084343, &phy->clk);
> > + writel(0x80084340 | (phy_div - 1), &phy->clk);
> >
> > mdelay(10);
> > writel(0x0001, &phy->unk3);
> > setbits_le32(&phy->pll, BIT(25));
> >
> > @@ -192,7 +192,7 @@ static void sunxi_dw_hdmi_phy_set(uint clock)
> >
> > break;
> >
> > case 11:
> > writel(0x39dc5040, &phy->pll);
> >
> > - writel(0x8008430a, &phy->clk);
> > + writel(0x80084300 | (phy_div - 1), &phy->clk);
> >
> >
Re: [U-Boot] [PATCH v1] apalis/colibri_imx6: add device trees to makefile
Hi Marcel, Could you please provide steps to reproduce this issue? I've double checked on the latest master of u-boot-imx, and can sucessfully build U-boot for Colibri iMX6DL (as an example). Thanks On Mon, Mar 25, 2019 at 6:38 PM Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > Add device trees to Makefile to avoid newly introduced error: > > Device Tree Source is not correctly specified. > Please define 'CONFIG_DEFAULT_DEVICE_TREE' > or build with 'DEVICE_TREE=' argument > > make[1]: *** [dts/Makefile:28: arch/arm/dts/imx6-apalis.dtb] Error 1 > make: *** [Makefile:1009: dts/dt.dtb] Error 2 > > Signed-off-by: Marcel Ziswiler > > --- > > arch/arm/dts/Makefile | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index e261c5936b..7b7ccfd204 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -481,6 +481,10 @@ dtb-$(CONFIG_MX6UL) += \ > > dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb > > +dtb-$(CONFIG_ARCH_MX6) += \ > + imx6-apalis.dtb \ > + imx6-colibri.dtb > + > dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \ > imx7d-sdb-qspi.dtb > > -- > 2.20.1 > > ___ > 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 09/22] configs: colibri_vf: disable obscure options
Hi Marcel, The actual line which does have impact is `CONFIG_DFU_MMC=y`. Not sure I understand the reason of adding "# ... is not set" lines in this defconfig. Could you please explain? Regards, Igor On Mon, Mar 25, 2019 at 6:30 PM Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > Disable more obscure options to save another 26 KB in preparation of > the upcoming driver model migration. > > Signed-off-by: Marcel Ziswiler > > --- > > Changes in v2: None > > configs/colibri_vf_defconfig | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig > index 8188582ed9..706d7ca634 100644 > --- a/configs/colibri_vf_defconfig > +++ b/configs/colibri_vf_defconfig > @@ -17,11 +17,17 @@ CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_HUSH_PARSER=y > # CONFIG_CMDLINE_EDITING is not set > # CONFIG_AUTO_COMPLETE is not set > +# CONFIG_SYS_LONGHELP is not set > CONFIG_SYS_PROMPT="Colibri VFxx # " > +# CONFIG_CMD_BOOTD is not set > +# CONFIG_CMD_BOOTM is not set > CONFIG_CMD_BOOTZ=y > +# CONFIG_CMD_ELF is not set > +# CONFIG_CMD_IMI is not set > CONFIG_CMD_ASKENV=y > CONFIG_CMD_MEMTEST=y > CONFIG_CMD_DFU=y > +# CONFIG_CMD_FLASH is not set > CONFIG_CMD_FUSE=y > CONFIG_CMD_GPIO=y > # CONFIG_CMD_LOADB is not set > @@ -46,10 +52,10 @@ CONFIG_DEFAULT_DEVICE_TREE="vf610-colibri" > CONFIG_ENV_IS_IN_NAND=y > CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y > CONFIG_DM=y > -CONFIG_DFU_MMC=y > CONFIG_DFU_NAND=y > CONFIG_DM_GPIO=y > CONFIG_VYBRID_GPIO=y > +# CONFIG_MMC_HW_PARTITIONING is not set > CONFIG_FSL_ESDHC=y > CONFIG_NAND_VF610_NFC=y > CONFIG_SYS_NAND_VF610_NFC_60_ECC_BYTES=y > @@ -57,6 +63,8 @@ CONFIG_MTD_UBI_FASTMAP=y > CONFIG_PHYLIB=y > CONFIG_PHY_MICREL=y > CONFIG_MII=y > +# CONFIG_SPL_SERIAL_PRESENT is not set > +# CONFIG_TPL_SERIAL_PRESENT is not set > CONFIG_DM_SERIAL=y > CONFIG_FSL_LPUART=y > CONFIG_USB=y > -- > 2.20.1 > > ___ > 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 v3 3/7] common: Implement A/B metadata
On Thu, Mar 28, 2019 at 05:30:30PM +0100, Eugeniu Rosca wrote: > Hello Igor, All, > > On Thu, Mar 21, 2019 at 05:39:36PM +0200, Igor Opaniuk wrote: > > Hi Eugeniu, > > > > On Fri, Mar 8, 2019 at 7:29 PM Eugeniu Rosca wrote: > [..] > > > > > > The s/uint8_t/u8/ and s/uint32_t/u32/ conversion creates noise > > > comparing the in-tree versus out-of-tree files and will add some > > > overhead during integration. I still see a lot of U-Boot code saying > > > uint8_t/uint32_t, so I wonder if these can be preserved. BTW, some of > > > the patches from this series add code using uint32_t. > > > > Agree. > > Igor, many thanks for the recent replies. > > WRT preserving the contents of the original bootloader_message.h from > https://android.googlesource.com/platform/bootable/recovery.git/ , I > wonder what's the chance of keeping the CPP comments in place when > importing the file in-tree, since it will make the diffs and subsequent > integration/updates easier from the source repository. Furthermore, we > don't expect any U-Boot specific development to be done in this file > in-tree. It should purely reflect the upstream state. > > I wonder if there is any official position regarding that from the > U-Boot maintainers? Yes, for stuff that we're importing from another place, and really really aren't touching otherwise, we should avoid changing it. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] arm: socfpga: stack and Kconfig cleanups
This series cleans up stack definitions in socfpga_common.h as well as cleans up defconfig files by implying/defaulting common things in Kconfig files. Finally, it reduces the malloc pool size used in first stage of gen5 SPL (without ddr available) in order to have more space available for code. As this series does not contain direct bugfixes, it targets the socfpga-next branch. Note that this series is meant for socfpga-next but depends on the generic series "spl: full-featured heap cleanups" from: https://patchwork.ozlabs.org/project/uboot/list/?series=99561 Changes in v3: - removed patch 2/5 from v2 (moved to patchwork #1067366, series #99561) - adapt to socfpge-next: imply USE_TINY_PRINTF only for gen5 & a10, not s10 Changes in v2: - fix commit message: "SPL post-reloc", not "SPL pre-reloc" - added patch to imply/default common config options - added patch to reduce gen5 SPL initial malloc pool to 2 KiB Simon Goldschmidt (4): arm: socfpga: fix comment about SPL memory layout arm: socfpga: put initial U-Boot stack into DDR arm: socfpga: imply/default common config options arm: socfpga: gen5: reduce SPL pre-reloc malloc arch/arm/Kconfig | 2 ++ arch/arm/mach-socfpga/Kconfig | 24 configs/socfpga_arria10_defconfig | 8 configs/socfpga_arria5_defconfig | 10 -- configs/socfpga_cyclone5_defconfig | 10 -- configs/socfpga_dbm_soc1_defconfig | 10 -- configs/socfpga_de0_nano_soc_defconfig | 10 -- configs/socfpga_de10_nano_defconfig| 10 -- configs/socfpga_de1_soc_defconfig | 10 -- configs/socfpga_is1_defconfig | 8 configs/socfpga_sockit_defconfig | 10 -- configs/socfpga_socrates_defconfig | 10 -- configs/socfpga_sr1500_defconfig | 10 -- configs/socfpga_stratix10_defconfig| 3 --- configs/socfpga_vining_fpga_defconfig | 10 -- include/configs/socfpga_common.h | 26 -- 16 files changed, 42 insertions(+), 129 deletions(-) -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] arm: socfpga: fix comment about SPL memory layout
The comment about SPL memory layout for socfpga gen5 is outdated: the initial malloc memory is now at the end of the SRAM, gd is below it (see board_init_f_alloc_reserve). Signed-off-by: Simon Goldschmidt --- Changes in v3: None Changes in v2: None include/configs/socfpga_common.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 24f8665c24..0c480fe4a4 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -236,9 +236,9 @@ unsigned int cm_get_qspi_controller_clk_hz(void); * * 0x_ .. Start of SRAM * 0x_ .. Top of stack (grows down) - * 0x_ .. Malloc area - * 0x_ .. Global Data - * 0x_FF00 .. End of SRAM + * 0x_ .. Global Data + * 0x_ .. Malloc area + * 0x_ .. End of SRAM * * SRAM Memory layout for Arria 10: * 0xFFE0_ .. Start of SRAM (bottom) -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] arm: socfpga: imply/default common config options
This commit moves common config options used in all socfpga boards to select/imply in Kconfig. This both cleans up the defconfig files as well as makes future changes easier. Options implied/defaulted for all sub-arches: - SPL, SPL_DM, USE_TINY_PRINTF, NR_DRAM_BANKS Options implied/defaulted for implied for A10 & gen5: - FPGA_SOCFPGA, SYS_MALLOC_F_LEN, SYS_TEXT_BASE Options implied/defaulted for A10: - SPL_SYS_MALLOC_F_LEN Options implied/defaulted for gen5: - SPL_STACK_R, SPL_SYS_MALLOC_SIMPLE, SPL_STACK_R_ADDR Signed-off-by: Simon Goldschmidt --- Changes in v3: - adapt to socfpge-next: imply USE_TINY_PRINTF only for gen5 & a10, not s10 Changes in v2: - added patch to imply/default common config options arch/arm/Kconfig | 2 ++ arch/arm/mach-socfpga/Kconfig | 23 +++ configs/socfpga_arria10_defconfig | 8 configs/socfpga_arria5_defconfig | 10 -- configs/socfpga_cyclone5_defconfig | 10 -- configs/socfpga_dbm_soc1_defconfig | 10 -- configs/socfpga_de0_nano_soc_defconfig | 10 -- configs/socfpga_de10_nano_defconfig| 10 -- configs/socfpga_de1_soc_defconfig | 10 -- configs/socfpga_is1_defconfig | 8 configs/socfpga_sockit_defconfig | 10 -- configs/socfpga_socrates_defconfig | 10 -- configs/socfpga_sr1500_defconfig | 10 -- configs/socfpga_stratix10_defconfig| 3 --- configs/socfpga_vining_fpga_defconfig | 10 -- 15 files changed, 25 insertions(+), 119 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f42eccef80..721f13641f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -839,6 +839,8 @@ config ARCH_SOCFPGA imply DM_SPI imply DM_SPI_FLASH imply FAT_WRITE + imply SPL + imply SPL_DM imply SPL_LIBDISK_SUPPORT imply SPL_MMC_SUPPORT imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 5e87371f8c..518bf9e821 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -1,8 +1,25 @@ if ARCH_SOCFPGA +config NR_DRAM_BANKS + default 1 + +config SPL_STACK_R_ADDR + default 0x0080 if TARGET_SOCFPGA_GEN5 + +config SPL_SYS_MALLOC_F_LEN + default 0x1 if TARGET_SOCFPGA_ARRIA10 + config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE default 0xa2 +config SYS_MALLOC_F_LEN + default 0x2000 if TARGET_SOCFPGA_ARRIA10 + default 0x2000 if TARGET_SOCFPGA_GEN5 + +config SYS_TEXT_BASE + default 0x0140 if TARGET_SOCFPGA_ARRIA10 + default 0x0140 if TARGET_SOCFPGA_GEN5 + config TARGET_SOCFPGA_ARRIA5 bool select TARGET_SOCFPGA_GEN5 @@ -21,6 +38,8 @@ config TARGET_SOCFPGA_ARRIA10 select SYSCON select SPL_SYSCON if SPL select ETH_DESIGNWARE_SOCFPGA + imply FPGA_SOCFPGA + imply USE_TINY_PRINTF config TARGET_SOCFPGA_CYCLONE5 bool @@ -29,6 +48,10 @@ config TARGET_SOCFPGA_CYCLONE5 config TARGET_SOCFPGA_GEN5 bool select ALTERA_SDRAM + imply FPGA_SOCFPGA + imply SPL_STACK_R + imply SPL_SYS_MALLOC_SIMPLE + imply USE_TINY_PRINTF config TARGET_SOCFPGA_STRATIX10 bool diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 094232e847..41c5b13cfd 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,13 +1,8 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y -CONFIG_SYS_TEXT_BASE=0x0140 -CONFIG_SYS_MALLOC_F_LEN=0x2000 -CONFIG_SPL_SYS_MALLOC_F_LEN=0x1 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y -CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" CONFIG_DISTRO_DEFAULTS=y -CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set @@ -30,9 +25,7 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y -CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y -CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y CONFIG_DM_MMC=y @@ -44,4 +37,3 @@ CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index 2f04092649..d514b14364 100644 --- a/configs/socfpga_arria5_defconfig +++ b/configs/socfpga_arria5_defconfig @@ -1,12 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y -CONFIG_SYS_TEXT_BASE=0x0140 -CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_SOCFPGA_ARRIA5_SOCDK=y -CONFIG_SPL=y -CONFIG_SPL_STACK_R_ADDR=0x0080 CONFIG_DISTRO_DEFAULTS=y -CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y # CONFIG_USE_BOOTCOMMAND is not set CONFIG_SYS_CONSOLE_IS_IN_ENV=y @@ -16,8 +11,6 @@ CONFIG_DEFAULT_FDT_FILE="socfpga_arria5_socdk.dtb" CONFIG_
[U-Boot] [PATCH v3 4/4] arm: socfpga: gen5: reduce SPL pre-reloc malloc
By enabling debug prints in malloc_simple, we can see that SPL for socfpga gen5 does by far not need the 8 KiB malloc pool currently allocated for SPL in pre-reloc phase. On socfpga_socrates, 1304 bytes are currently used (and this increases by ~200 bytes only for the sdram/reset fixes in socfpga-next). To prevent wasting precious SRAM space, let's reduce the initial heap used for SPL to 2 KiB. This is still some hundred bytes more than currently used. Also, the gen5 SPL enables stack and heap in DDR memory pretty early. Only the initial uclass/dm parsing, serial console and DDR initialization is done in the initial heap, so these 2 KiB should be enough for all boards. Signed-off-by: Simon Goldschmidt --- Changes in v3: None Changes in v2: - added patch to reduce gen5 SPL initial malloc pool to 2 KiB arch/arm/mach-socfpga/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 518bf9e821..1ebcfe6a64 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -8,6 +8,7 @@ config SPL_STACK_R_ADDR config SPL_SYS_MALLOC_F_LEN default 0x1 if TARGET_SOCFPGA_ARRIA10 + default 0x800 if TARGET_SOCFPGA_GEN5 config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE default 0xa2 -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] arm: socfpga: put initial U-Boot stack into DDR
If SPL post-reloc stage puts the stack into DDR, U-Boot should be able to do that, too. The reason to do so is that this way, U-Boot initial stack can be larger than SPL initial stack. In situations where we want to save the SPL in SRAM for next boot without reloading, this prevents overwriting the SPL DTB in SRAM if U-Boot stack usage gets too high. Signed-off-by: Simon Goldschmidt --- Changes in v3: - removed patch 2/5 from v2 (moved to patchwork #1067366, series #99561) Changes in v2: - fix commit message: "SPL post-reloc", not "SPL pre-reloc" include/configs/socfpga_common.h | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 0c480fe4a4..bb55ab79dd 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -38,12 +38,23 @@ #if ((CONFIG_SYS_BOOTCOUNT_ADDR > CONFIG_SYS_INIT_RAM_ADDR) && \ (CONFIG_SYS_BOOTCOUNT_ADDR < (CONFIG_SYS_INIT_RAM_ADDR + \ CONFIG_SYS_INIT_RAM_SIZE))) -#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SYS_BOOTCOUNT_ADDR +#define CONFIG_SPL_STACK CONFIG_SYS_BOOTCOUNT_ADDR #else -#define CONFIG_SYS_INIT_SP_ADDR\ +#define CONFIG_SPL_STACK \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE) #endif +/* + * U-Boot stack setup: if SPL post-reloc uses DDR stack, use it in pre-reloc + * phase of U-Boot, too. This prevents overwriting SPL data if stack/heap usage + * in U-Boot pre-reloc is higher than in SPL. + */ +#if defined(CONFIG_SPL_STACK_R_ADDR) && CONFIG_SPL_STACK_R_ADDR +#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SPL_STACK_R_ADDR +#else +#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SPL_STACK +#endif + #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 /* @@ -282,11 +293,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #endif #endif -/* - * Stack setup - */ -#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR - /* Extra Environment */ #ifndef CONFIG_SPL_BUILD -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] arm: socfpga: enable rtc support for the socrates board
This series contains fixes and config changes to enable the 'date' command talking to the rtc on the socrates board. It contains fixes to the designware i2c driver, enables DM support for the rtc used on the socrates board, adds a missing pull-up and changes the defconfig to enable rtc support by default. This patch applies to socfpga-next. Changes in v3: - pick up missing reviewed-by from v1 - pick up missing reviewed-by from v1 - pick up missing reviewed-by from v1 - pick up missing reviewed-by from v1 Changes in v2: - m41t82: reset HT bit during probe Simon Goldschmidt (4): i2c: designware: fix reset handling on socfpga gen5 rtc: m41t62: add compatible for m41t82 arm: socfpga: socrates: make rtc work configs: socfpga: socrates: enable rtc support board/ebv/socrates/qts/iocsr_config.h | 2 +- configs/socfpga_socrates_defconfig| 2 ++ drivers/i2c/designware_i2c.c | 20 ++-- drivers/rtc/m41t62.c | 11 +++ 4 files changed, 28 insertions(+), 7 deletions(-) -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] i2c: designware: fix reset handling on socfpga gen5
Using this driver on socfpga gen5 with DM_I2C enabled leads to a data abort
as the 'i2c' reset property cannot be found (the gen5 dtsi does not provide
reset-names).
The actual bug was to check 'if (&priv->reset_ctl)', which is never false.
While at it, convert the driver to use 'reset_get_bulk' instead of looking
at a specific named reset and also make it release the reset on driver
remove before starting the OS.
Fixes: 622597dee4f6 ("i2c: designware: add reset ctrl to driver")
Signed-off-by: Simon Goldschmidt
Reviewed-by: Heiko Schocher
---
Changes in v3:
- pick up missing reviewed-by from v1
Changes in v2: None
drivers/i2c/designware_i2c.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 63e40823f1..9ccc2411a6 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -34,7 +34,7 @@ static struct dw_scl_sda_cfg byt_config = {
struct dw_i2c {
struct i2c_regs *regs;
struct dw_scl_sda_cfg *scl_sda_cfg;
- struct reset_ctl reset_ctl;
+ struct reset_ctl_bulk resets;
};
#ifdef CONFIG_SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED
@@ -562,16 +562,22 @@ static int designware_i2c_probe(struct udevice *bus)
priv->regs = (struct i2c_regs *)devfdt_get_addr_ptr(bus);
}
- ret = reset_get_by_name(bus, "i2c", &priv->reset_ctl);
+ ret = reset_get_bulk(bus, &priv->resets);
if (ret)
- pr_info("reset_get_by_name() failed: %d\n", ret);
-
- if (&priv->reset_ctl)
- reset_deassert(&priv->reset_ctl);
+ dev_warn(bus, "Can't get reset: %d\n", ret);
+ else
+ reset_deassert_bulk(&priv->resets);
return __dw_i2c_init(priv->regs, 0, 0);
}
+static int designware_i2c_remove(struct udevice *dev)
+{
+ struct dw_i2c *priv = dev_get_priv(dev);
+
+ return reset_release_bulk(&priv->resets);
+}
+
static int designware_i2c_bind(struct udevice *dev)
{
static int num_cards;
@@ -613,6 +619,8 @@ U_BOOT_DRIVER(i2c_designware) = {
.bind = designware_i2c_bind,
.probe = designware_i2c_probe,
.priv_auto_alloc_size = sizeof(struct dw_i2c),
+ .remove = designware_i2c_remove,
+ .flags = DM_FLAG_OS_PREPARE,
.ops= &designware_i2c_ops,
};
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] arm: socfpga: socrates: make rtc work
This patch makes the on-board RTC work on the socfpga_socrates board.
This rtc is present on the board, but it does not work (fails with a
timeout).
This patch adds a weak pull-up on the I2C0-SCL pin connected to the m41t82
RTC on this board. While the SDA line has a pull-up on the pcb, the pull-up
on the SCL line seems to be missing. To work around this, enable the
weak-pull-up feature on this pin.
After applying this patch, the rtc timeout is gone and the 'date' command
can access the rtc chip.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Stefan Roese
---
Changes in v3:
- pick up missing reviewed-by from v1
Changes in v2: None
board/ebv/socrates/qts/iocsr_config.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ebv/socrates/qts/iocsr_config.h
b/board/ebv/socrates/qts/iocsr_config.h
index 011fa2bac3..18b9c6ce4d 100644
--- a/board/ebv/socrates/qts/iocsr_config.h
+++ b/board/ebv/socrates/qts/iocsr_config.h
@@ -108,7 +108,7 @@ const unsigned long iocsr_scan_chain2_table[] = {
0x00018004,
0x06001209,
0x4000,
- 0x20002412,
+ 0x20042412,
0x00904800,
0x0030,
0x8000,
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] configs: socfpga: socrates: enable rtc support
This enables DM_RTC and RTC_M41T62 to enable support for the rtc on the socrates board. Signed-off-by: Simon Goldschmidt Reviewed-by: Stefan Roese --- Changes in v3: - pick up missing reviewed-by from v1 Changes in v2: None configs/socfpga_socrates_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/socfpga_socrates_defconfig b/configs/socfpga_socrates_defconfig index 45fd78a15c..242d938f9c 100644 --- a/configs/socfpga_socrates_defconfig +++ b/configs/socfpga_socrates_defconfig @@ -61,6 +61,8 @@ CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y CONFIG_DM_RESET=y +CONFIG_DM_RTC=y +CONFIG_RTC_M41T62=y CONFIG_SPI=y CONFIG_CADENCE_QSPI=y CONFIG_DESIGNWARE_SPI=y -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] rtc: m41t62: add compatible for m41t82
This adds a compatible string for m41t82. This ensures that this driver
can be used for m41t82 in DM mode, too (asit was usable for this model in
non-DM mode before).
In addition, the HT bit has to be reset during probe, since the m41t82
chip sets it when entering battery standby mode.
This patch ensures this driver works on socfpga_socrates.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Stefan Roese
---
Changes in v3:
- pick up missing reviewed-by from v1
Changes in v2:
- m41t82: reset HT bit during probe
drivers/rtc/m41t62.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index 2ee7e00b02..6161b76712 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -155,6 +155,15 @@ static int m41t62_rtc_reset(struct udevice *dev)
return ret;
}
+/*
+ * Make sure HT bit is cleared. This bit is set on entering battery backup
+ * mode, so do this before the first read access.
+ */
+static int m41t62_rtc_probe(struct udevice *dev)
+{
+ return m41t62_rtc_reset(dev);
+}
+
static const struct rtc_ops m41t62_rtc_ops = {
.get = m41t62_rtc_get,
.set = m41t62_rtc_set,
@@ -163,6 +172,7 @@ static const struct rtc_ops m41t62_rtc_ops = {
static const struct udevice_id m41t62_rtc_ids[] = {
{ .compatible = "st,m41t62" },
+ { .compatible = "st,m41t82" },
{ .compatible = "microcrystal,rv4162" },
{ }
};
@@ -172,6 +182,7 @@ U_BOOT_DRIVER(rtc_m41t62) = {
.id = UCLASS_RTC,
.of_match = m41t62_rtc_ids,
.ops= &m41t62_rtc_ops,
+ .probe = &m41t62_rtc_probe,
};
#else /* NON DM RTC code - will be removed */
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] socfpga: add Simon Goldschmidt as co-custodian
This updates MAINTAINERS and git-mailrc to add me as a co-custodian for socfpga. Signed-off-by: Simon Goldschmidt --- MAINTAINERS| 1 + doc/git-mailrc | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8a4c5d4eab..37e2baca80 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -82,6 +82,7 @@ F:arch/arm/ ARM ALTERA SOCFPGA M: Marek Vasut +M: Simon Goldschmidt S: Maintainted T: git git://git.denx.de/u-boot-socfpga.git F: arch/arm/mach-socfpga/ diff --git a/doc/git-mailrc b/doc/git-mailrc index c2eee8c7d8..768c3ff926 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -39,6 +39,7 @@ alias prafulla Prafulla Wadaskar alias prom Minkyu Kang alias ptomsich Philipp Tomsich alias sbabic Stefano Babic +alias simongoldschmidt Simon Goldschmidt alias sjgSimon Glass alias smcnuttScott McNutt alias stroeseStefan Roese @@ -64,7 +65,7 @@ alias s3csamsung alias s5pc samsung alias samsunguboot, prom alias snapdragon uboot, mateusz -alias socfpgauboot, marex, dinh +alias socfpgauboot, marex, dinh, simongoldschmidt alias sunxi uboot, jagan, maxime alias tegra uboot, sjg, Tom Warren , Stephen Warren alias tegra2 tegra -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] doc/git-mailrc: correct entry 'agraf'
Correct Alex's email address. Signed-off-by: Heinrich Schuchardt --- doc/git-mailrc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/git-mailrc b/doc/git-mailrc index c2eee8c7d8..b75ebab02b 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -15,7 +15,7 @@ alias abiessmann Andreas Bießmann alias abrodkin Alexey Brodkin alias afleming Andy Fleming alias ag Anatolij Gustschin -alias agraf Alexander Graf +alias agraf Alexander Graf alias alisonwang Alison Wang alias angelo_ts Angelo Dureghello alias bmeng Bin Meng -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] colibri_vf: fix tab vs. spaces
From: Marcel Ziswiler Fix indentation using tab vs. spaces. Signed-off-by: Marcel Ziswiler --- board/toradex/colibri_vf/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/toradex/colibri_vf/MAINTAINERS b/board/toradex/colibri_vf/MAINTAINERS index 3ee2b33152..66b2150986 100644 --- a/board/toradex/colibri_vf/MAINTAINERS +++ b/board/toradex/colibri_vf/MAINTAINERS @@ -1,7 +1,7 @@ Colibri VFxx M: Stefan Agner W: http://developer.toradex.com/software/linux/linux-software -W: https://www.toradex.com/community +W: https://www.toradex.com/community S: Maintained F: board/toradex/colibri_vf/ F: include/configs/colibri_vf.h -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] colibri_vf: fix ethernet by adding explicit phy node
From: Marcel Ziswiler
The implicit fallback mechanism for searching the whole MDIO bus for at
least one PHY has been gone with the following commit b882005a18de
("drivers/net/fec: phy_init: remove redundant logic"). This lead to the
Ethernet driver erroring out as follows:
Net: Could not get PHY for FEC0: addr -19
eth-1: fec@400d1000
Colibri VFxx # dhcp
Could not get PHY for FEC0: addr -19
Could not get PHY for FEC0: addr -19
Could not get PHY for FEC0: addr -19
Could not get PHY for FEC0: addr -19
No ethernet found.
Could not get PHY for FEC0: addr -19
Colibri VFxx #
This commit adds an explicit PHY node which makes it work again.
Signed-off-by: Marcel Ziswiler
---
arch/arm/dts/vf-colibri.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/vf-colibri.dtsi b/arch/arm/dts/vf-colibri.dtsi
index 5ce17076e9..91ca4e4ddd 100644
--- a/arch/arm/dts/vf-colibri.dtsi
+++ b/arch/arm/dts/vf-colibri.dtsi
@@ -60,11 +60,24 @@
status = "okay";
};
+/* Ethernet */
&fec1 {
phy-mode = "rmii";
+ phy-handle = <ðphy1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec1>;
status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ max-speed = <100>;
+ reg = <1>;
+ };
+ };
};
&i2c0 {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC] simple address definition method for early TPL/SPL
Hi U-Boot Maintainers: The use-case is: - A register address is needed for a function init, eg. stimer init, boot mode detect; - It's a per-SoC config, the address is not the same for different SoCs; - The driver can be just the same other than the address itself is different; - The address will be used very early in SPL/TPL; There is no no effective communication other than the requirement from the maintainer in the whole passed *YEAR*, while the requirement does not make sense to this case. And no matter how I explain why I implement the patch in this format over and over, there is no response to my explanation but only the same 'change request'. I have no experience on mainline U-Boot maintain, but I do maintain a lot of other project, and I have to convince others and get agreement if I ask for implement in my way. It has pending for such a lng time, and I would like to close this topic and update all related source code, you can find the previous discussion at [0][1]. Philipp object this patch and his original reason is: > This should not be in Kconfig and rather in a header-file. > With what you do here, a user (e.g. via 'make menuconfig') or a defconfig > file (e.g. due to a typo) could accidentially change overwrite this. and Philipp also think: > asm/arch-rockchip would be preferable over include/config as a header There are many ways for feature configure on rockchip platform now: - board dts; - header file in 'include/config' - Kconfig in $(BOARD)_defconfig - Kconfig default value in 'Kconfig' file Already too many place to config, we should make it simple rather than complex. I think people are migrating more and more configurations from header file to Kconfig, including: - option for enable/disable modules; - option for module parameter which is numerical value; - option for module parameter which is string; I think the target is that most of the configs goes to Kconfig and user can config options with menuconfig and no need to touch header file(Please tell me if this is not true). And for all those config options, I think at lease can be separate into two kind: - options per-board; - options per-soc (some of them may per-vendor); I think the idealized model would be per-soc options goes to 'Kconfig' file with default value combine with SOC, and per-board options at $(BOARD)_defconfig. ROCKCHIP_STIMER_REG(another case is BOOT_MODE_REG) is per-soc config option, just like SYS_TEXT_BASE, TPL_TEXT_BASE, TPL_MAX_SIZE, SYS_SOC and so on. Driver for different SOCs to use this reg are just the same, and this reg needs to be used very early in TPL/SPL which means no DM, no dts available. Here are the solutions from previous discussion: - dts (by Simon) extra dtb code needed, setting separate into individual board dts; not available and not suggestion to use in TPL/SPL; - move to header in 'asm/arch-rockchip' (by Philipp) one more place to config, make config options more complicate; may separate in more than 10+ files for different soc/board; - RMII setting like, (by Philipp) reference to 'drivers/net/gmac_rockchip.c', driver for different SoCs are not re-usable, driver needs to update for each new SoC support; not available with DM in early TPL/SPL; - Kconfig with default value in this patch Keep driver clean and no need to update with new SoC; One place rather than 10+ individual files, same usage like SYS_TEXT_BASE, reference to: 341c058654 sunxi: move CONFIG_SYS_TEXT_BASE out of defconfigs I think the default value in Kconfig is the best solution, the SPL/TPL should be small, fast and with enough functionality for use. Thanks, - Kever [0] https://patchwork.ozlabs.org/patch/1004148/ [1] http://patchwork.ozlabs.org/patch/891462/ Kever Yang mailto:kever.y...@rock-chips.com>> 于2018年3月27日周二 下午5:30写道： STIMER is can only access in secure mode if the SoCs supports trust, and it locate in alive power domain, as the source of ARM arch/generic timer, we add a base addr for all SoCs so that we can init with a common function. Signed-off-by: Kever Yang mailto:kever.y...@rock-chips.com>> --- arch/arm/mach-rockchip/Kconfig | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 007cb22..5dfe452 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -190,6 +190,25 @@ config ROCKCHIP_BOOT_MODE_REG The Soc will enter to different boot mode(defined in asm/arch/boot_mode.h) according to the value from this register. +config ROCKCHIP_STIMER_BASE + hex "Rockchip Secure timer base address" + default 0xff220020 if ROCKCHIP_PX30 + default 0x200440a0 if ROCKCHIP_RK3036 + default 0x2000e000 if ROCKCHIP_RK3066 + default 0x20018020 if ROCKCHIP_RK3126 + default 0x200440a0 if ROCKCHIP_RK3128 +
[U-Boot] [PATCH v2 01/10] rockchip: enable DEBUG_UART_BOARD_INIT by default
All Rockchip SoCs use DEBUG_UART_BOARD_INIT to init per board UART IOMUX, enable it by default. Signed-off-by: Kever Yang --- arch/arm/Kconfig | 1 + arch/arm/mach-rockchip/Kconfig | 4 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f42eccef80..a5851aeeae 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1432,6 +1432,7 @@ config ARCH_ROCKCHIP select SYS_THUMB_BUILD if !ARM64 imply ADC imply CMD_DM + imply DEBUG_UART_BOARD_INIT imply DISTRO_DEFAULTS imply FAT_WRITE imply SARADC_ROCKCHIP diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 7e5a73f92c..17b3b9372d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -34,7 +34,6 @@ config ROCKCHIP_RK3188 select SPL_RAM select SPL_DRIVERS_MISC_SUPPORT select SPL_ROCKCHIP_EARLYRETURN_TO_BROM - select DEBUG_UART_BOARD_INIT select BOARD_LATE_INIT select ROCKCHIP_BROM_HELPER help @@ -50,7 +49,6 @@ config ROCKCHIP_RK322X select SUPPORT_SPL select SPL select ROCKCHIP_BROM_HELPER - select DEBUG_UART_BOARD_INIT help The Rockchip RK3229 is a ARM-based SoC with a dual-core Cortex-A7 including NEON and GPU, Mali-400 graphics, several DDR3 options @@ -102,7 +100,6 @@ config ROCKCHIP_RK3368 imply SPL_SEPARATE_BSS imply SPL_SERIAL_SUPPORT imply TPL_SERIAL_SUPPORT - select DEBUG_UART_BOARD_INIT help The Rockchip RK3368 is a ARM-based SoC with a octa-core (organised into a big and little cluster with 4 cores each) Cortex-A53 including @@ -135,7 +132,6 @@ config ROCKCHIP_RK3399 select SPL_SEPARATE_BSS select SPL_SERIAL_SUPPORT select SPL_DRIVERS_MISC_SUPPORT - select DEBUG_UART_BOARD_INIT select BOARD_LATE_INIT select ROCKCHIP_BROM_HELPER help -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 00/10] rockchip: enable board_debug_uart_init for all soc
ALl rockchip soc use DEBUG UART, and need init the uart iomux in board_debug_uart_init(). Move the board_debug_uart_init() into soc file so that we can make all soc config in soc file and share a common board file later for all rockchip SoCs. Verison 2 rebase on master with 'SYS_SOC name correction' patch set. This patchset has been test on: rk3036, rk3188, rk3229, rk3288, rk3328, rk3368, rk3399, rv1108 Kever Yang (10): rockchip: enable DEBUG_UART_BOARD_INIT by default rockchip; kylin-rk3036: enabl DEBUG UART rockchip: rk3036: add board_debug_uart_init() rockchip: rk3188: add board_debug_uart_init() rockchip: rk322x: move board_debug_uart_init() to rk322x.c rockchip: rk3288: use grf structure to access soc_con2 rockchip: rk3288: add board_debug_uart_init() rockchip: rk3368: move board_debug_uart_init() to rk3368.c rockchip: rk3399: use grf structure to access reg rockchip: rk3399: add board_debug_uart_init() arch/arm/Kconfig | 1 + arch/arm/mach-rockchip/Kconfig| 4 -- arch/arm/mach-rockchip/rk3036-board-spl.c | 20 + arch/arm/mach-rockchip/rk3036/Makefile| 1 + arch/arm/mach-rockchip/rk3036/rk3036.c| 39 arch/arm/mach-rockchip/rk3188-board-spl.c | 28 +--- arch/arm/mach-rockchip/rk3188/Makefile| 1 + arch/arm/mach-rockchip/rk3188/rk3188.c| 36 +++ arch/arm/mach-rockchip/rk322x-board-spl.c | 44 +- arch/arm/mach-rockchip/rk322x-board.c | 30 + arch/arm/mach-rockchip/rk322x/Makefile| 2 +- arch/arm/mach-rockchip/rk322x/rk322x.c| 44 ++ arch/arm/mach-rockchip/rk3288-board-spl.c | 12 + arch/arm/mach-rockchip/rk3288-board-tpl.c | 16 +-- arch/arm/mach-rockchip/rk3288/rk3288.c| 19 +++- arch/arm/mach-rockchip/rk3368-board-spl.c | 8 arch/arm/mach-rockchip/rk3368-board-tpl.c | 33 +- arch/arm/mach-rockchip/rk3368/rk3368.c| 31 + arch/arm/mach-rockchip/rk3399-board-spl.c | 50 + arch/arm/mach-rockchip/rk3399/rk3399.c| 55 ++- configs/kylin-rk3036_defconfig| 4 ++ 21 files changed, 240 insertions(+), 238 deletions(-) create mode 100644 arch/arm/mach-rockchip/rk3036/rk3036.c create mode 100644 arch/arm/mach-rockchip/rk3188/rk3188.c create mode 100644 arch/arm/mach-rockchip/rk322x/rk322x.c -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/10] rockchip: rk3036: add board_debug_uart_init()
Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk3036-board-spl.c | 20 +---
arch/arm/mach-rockchip/rk3036/Makefile| 1 +
arch/arm/mach-rockchip/rk3036/rk3036.c| 39 +++
3 files changed, 41 insertions(+), 19 deletions(-)
create mode 100644 arch/arm/mach-rockchip/rk3036/rk3036.c
diff --git a/arch/arm/mach-rockchip/rk3036-board-spl.c
b/arch/arm/mach-rockchip/rk3036-board-spl.c
index b897ffeae2..110d06dba5 100644
--- a/arch/arm/mach-rockchip/rk3036-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3036-board-spl.c
@@ -7,30 +7,12 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
-
-#define GRF_BASE 0x20008000
-
-#define DEBUG_UART_BASE0x20068000
void board_init_f(ulong dummy)
{
-#ifdef EARLY_DEBUG
- struct rk3036_grf * const grf = (void *)GRF_BASE;
- /*
-* NOTE: sd card and debug uart use same iomux in rk3036,
-* so if you enable uart,
-* you can not boot from sdcard
-*/
- rk_clrsetreg(&grf->gpio1c_iomux,
-GPIO1C3_MASK << GPIO1C3_SHIFT |
-GPIO1C2_MASK << GPIO1C2_SHIFT,
-GPIO1C3_UART2_SOUT << GPIO1C3_SHIFT |
-GPIO1C2_UART2_SIN << GPIO1C2_SHIFT);
+#ifdef CONFIG_DEBUG_UART
debug_uart_init();
#endif
rockchip_timer_init();
diff --git a/arch/arm/mach-rockchip/rk3036/Makefile
b/arch/arm/mach-rockchip/rk3036/Makefile
index 20d28f7c21..299fc50635 100644
--- a/arch/arm/mach-rockchip/rk3036/Makefile
+++ b/arch/arm/mach-rockchip/rk3036/Makefile
@@ -10,4 +10,5 @@ ifndef CONFIG_SPL_BUILD
obj-y += syscon_rk3036.o
endif
+obj-y += rk3036.o
obj-y += sdram_rk3036.o
diff --git a/arch/arm/mach-rockchip/rk3036/rk3036.c
b/arch/arm/mach-rockchip/rk3036/rk3036.c
new file mode 100644
index 00..32426ac840
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3036/rk3036.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 Rockchip Electronics Co., Ltd
+ */
+#include
+#include
+#include
+
+#ifdef CONFIG_DEBUG_UART_BOARD_INIT
+void board_debug_uart_init(void)
+{
+#define GRF_BASE 0x20008000
+ struct rk3036_grf * const grf = (void *)GRF_BASE;
+ enum {
+ GPIO1C3_SHIFT = 6,
+ GPIO1C3_MASK= 3 << GPIO1C3_SHIFT,
+ GPIO1C3_GPIO= 0,
+ GPIO1C3_MMC0_D1,
+ GPIO1C3_UART2_SOUT,
+
+ GPIO1C2_SHIFT = 4,
+ GPIO1C2_MASK= 3 << GPIO1C2_SHIFT,
+ GPIO1C2_GPIO= 0,
+ GPIO1C2_MMC0_D0,
+ GPIO1C2_UART2_SIN,
+ };
+ /*
+* NOTE: sd card and debug uart use same iomux in rk3036,
+* so if you enable uart,
+* you can not boot from sdcard
+*/
+ rk_clrsetreg(&grf->gpio1c_iomux,
+GPIO1C3_MASK << GPIO1C3_SHIFT |
+GPIO1C2_MASK << GPIO1C2_SHIFT,
+GPIO1C3_UART2_SOUT << GPIO1C3_SHIFT |
+GPIO1C2_UART2_SIN << GPIO1C2_SHIFT);
+}
+#endif
+
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 02/10] rockchip; kylin-rk3036: enabl DEBUG UART
Enable debug uart for kylin board in defconfig. Signed-off-by: Kever Yang --- configs/kylin-rk3036_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/kylin-rk3036_defconfig b/configs/kylin-rk3036_defconfig index d6d5abb2b6..fca3c238f7 100644 --- a/configs/kylin-rk3036_defconfig +++ b/configs/kylin-rk3036_defconfig @@ -7,7 +7,10 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_ROCKCHIP_RK3036=y CONFIG_TARGET_KYLIN_RK3036=y CONFIG_SPL_SYS_MALLOC_F_LEN=0x0 +CONFIG_DEBUG_UART_BASE=0x20068000 +CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_STACK_R_ADDR=0x8 +CONFIG_DEBUG_UART=y CONFIG_NR_DRAM_BANKS=1 # CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_DEFAULT_FDT_FILE="rk3036-kylin.dtb" @@ -44,6 +47,7 @@ CONFIG_SPI_FLASH=y CONFIG_PINCTRL=y CONFIG_DM_REGULATOR_FIXED=y # CONFIG_SPL_DM_SERIAL is not set +CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_DWC2=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 06/10] rockchip: rk3288: use grf structure to access soc_con2
Prefer to use structure to access register if we can.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk3288/rk3288.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index af3a465cc3..987fae544c 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -4,15 +4,17 @@
*/
#include
#include
+#include
-#define GRF_SOC_CON2 0xff77024c
+#define GRF_BASE 0xff77
int arch_cpu_init(void)
{
/* We do some SoC one time setting here. */
+ struct rk3288_grf * const grf = (void *)GRF_BASE;
/* Use rkpwm by default */
- rk_setreg(GRF_SOC_CON2, 1 << 0);
+ rk_setreg(&grf->soc_con2, 1 << 0);
return 0;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/10] rockchip: rk3368: move board_debug_uart_init() to rk3368.c
Move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file later for all rockchip SoCs.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk3368-board-spl.c | 8 --
arch/arm/mach-rockchip/rk3368-board-tpl.c | 33 +--
arch/arm/mach-rockchip/rk3368/rk3368.c| 31 +
3 files changed, 32 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3368-board-spl.c
b/arch/arm/mach-rockchip/rk3368-board-spl.c
index 9dea4ed994..b055ed4aee 100644
--- a/arch/arm/mach-rockchip/rk3368-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3368-board-spl.c
@@ -9,17 +9,9 @@
#include
#include
#include
-#include
-#include
-#include
#include
-#include
#include
-void board_debug_uart_init(void)
-{
-}
-
void board_init_f(ulong dummy)
{
struct udevice *pinctrl;
diff --git a/arch/arm/mach-rockchip/rk3368-board-tpl.c
b/arch/arm/mach-rockchip/rk3368-board-tpl.c
index 373f009414..dc65a021c8 100644
--- a/arch/arm/mach-rockchip/rk3368-board-tpl.c
+++ b/arch/arm/mach-rockchip/rk3368-board-tpl.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
@@ -79,42 +78,12 @@ static void sgrf_init(void)
rk_clrreg(&cru->softrst_con[4], DMA2_SRST_REQ);
}
-void board_debug_uart_init(void)
-{
- /*
-* N.B.: This is called before the device-model has been
-* initialised. For this reason, we can not access
-* the GRF address range using the syscon API.
-*/
- struct rk3368_grf * const grf =
- (struct rk3368_grf * const)0xff77;
-
- enum {
- GPIO2D1_MASK= GENMASK(3, 2),
- GPIO2D1_GPIO= 0,
- GPIO2D1_UART0_SOUT = (1 << 2),
-
- GPIO2D0_MASK= GENMASK(1, 0),
- GPIO2D0_GPIO= 0,
- GPIO2D0_UART0_SIN = (1 << 0),
- };
-
-#if defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff18)
- /* Enable early UART0 on the RK3368 */
- rk_clrsetreg(&grf->gpio2d_iomux,
-GPIO2D0_MASK, GPIO2D0_UART0_SIN);
- rk_clrsetreg(&grf->gpio2d_iomux,
-GPIO2D1_MASK, GPIO2D1_UART0_SOUT);
-#endif
-}
-
void board_init_f(ulong dummy)
{
struct udevice *dev;
int ret;
-#define EARLY_UART
-#ifdef EARLY_UART
+#ifdef CONFIG_DEBUG_UART
/*
* Debug UART can be used from here if required:
*
diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c
b/arch/arm/mach-rockchip/rk3368/rk3368.c
index 197f0c485a..1ed06c5352 100644
--- a/arch/arm/mach-rockchip/rk3368/rk3368.c
+++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
@@ -96,3 +96,34 @@ int arch_early_init_r(void)
return mcu_init();
}
#endif
+
+#ifdef CONFIG_DEBUG_UART_BOARD_INIT
+void board_debug_uart_init(void)
+{
+ /*
+* N.B.: This is called before the device-model has been
+* initialised. For this reason, we can not access
+* the GRF address range using the syscon API.
+*/
+#if defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff18)
+ struct rk3368_grf * const grf =
+ (struct rk3368_grf * const)0xff77;
+
+ enum {
+ GPIO2D1_MASK= GENMASK(3, 2),
+ GPIO2D1_GPIO= 0,
+ GPIO2D1_UART0_SOUT = (1 << 2),
+
+ GPIO2D0_MASK= GENMASK(1, 0),
+ GPIO2D0_GPIO= 0,
+ GPIO2D0_UART0_SIN = (1 << 0),
+ };
+
+ /* Enable early UART0 on the RK3368 */
+ rk_clrsetreg(&grf->gpio2d_iomux,
+GPIO2D0_MASK, GPIO2D0_UART0_SIN);
+ rk_clrsetreg(&grf->gpio2d_iomux,
+GPIO2D1_MASK, GPIO2D1_UART0_SOUT);
+#endif
+}
+#endif
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/10] rockchip: rk322x: move board_debug_uart_init() to rk322x.c
Move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file later for all rockchip SoCs.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk322x-board-spl.c | 44 ++-
arch/arm/mach-rockchip/rk322x-board.c | 30 +---
arch/arm/mach-rockchip/rk322x/Makefile| 2 +-
arch/arm/mach-rockchip/rk322x/rk322x.c| 44 +++
4 files changed, 48 insertions(+), 72 deletions(-)
create mode 100644 arch/arm/mach-rockchip/rk322x/rk322x.c
diff --git a/arch/arm/mach-rockchip/rk322x-board-spl.c
b/arch/arm/mach-rockchip/rk322x-board-spl.c
index c50130c3b5..888310efbe 100644
--- a/arch/arm/mach-rockchip/rk322x-board-spl.c
+++ b/arch/arm/mach-rockchip/rk322x-board-spl.c
@@ -10,54 +10,13 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
u32 spl_boot_device(void)
{
return BOOT_DEVICE_MMC1;
}
-#define GRF_BASE 0x1100
-#define SGRF_BASE 0x1014
-
-#define DEBUG_UART_BASE0x1103
-
-void board_debug_uart_init(void)
-{
- static struct rk322x_grf * const grf = (void *)GRF_BASE;
- enum {
- GPIO1B2_SHIFT = 4,
- GPIO1B2_MASK= 3 << GPIO1B2_SHIFT,
- GPIO1B2_GPIO= 0,
- GPIO1B2_UART1_SIN,
- GPIO1B2_UART21_SIN,
-
- GPIO1B1_SHIFT = 2,
- GPIO1B1_MASK= 3 << GPIO1B1_SHIFT,
- GPIO1B1_GPIO= 0,
- GPIO1B1_UART1_SOUT,
- GPIO1B1_UART21_SOUT,
- };
- enum {
- CON_IOMUX_UART2SEL_SHIFT= 8,
- CON_IOMUX_UART2SEL_MASK = 1 << CON_IOMUX_UART2SEL_SHIFT,
- CON_IOMUX_UART2SEL_2= 0,
- CON_IOMUX_UART2SEL_21,
- };
-
- /* Enable early UART2 channel 1 on the RK322x */
- rk_clrsetreg(&grf->gpio1b_iomux,
-GPIO1B1_MASK | GPIO1B2_MASK,
-GPIO1B2_UART21_SIN << GPIO1B2_SHIFT |
-GPIO1B1_UART21_SOUT << GPIO1B1_SHIFT);
- /* Set channel C as UART2 input */
- rk_clrsetreg(&grf->con_iomux,
-CON_IOMUX_UART2SEL_MASK,
-CON_IOMUX_UART2SEL_21 << CON_IOMUX_UART2SEL_SHIFT);
-}
#define SGRF_DDR_CON0 0x1015
void board_init_f(ulong dummy)
@@ -65,6 +24,7 @@ void board_init_f(ulong dummy)
struct udevice *dev;
int ret;
+#ifdef CONFIG_DEBUG_UART
/*
* Debug UART can be used from here if required:
*
@@ -75,7 +35,7 @@ void board_init_f(ulong dummy)
*/
debug_uart_init();
printascii("SPL Init");
-
+#endif
ret = spl_early_init();
if (ret) {
debug("spl_early_init() failed: %d\n", ret);
diff --git a/arch/arm/mach-rockchip/rk322x-board.c
b/arch/arm/mach-rockchip/rk322x-board.c
index 9aad6bb0bc..d24f7c959d 100644
--- a/arch/arm/mach-rockchip/rk322x-board.c
+++ b/arch/arm/mach-rockchip/rk322x-board.c
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
DECLARE_GLOBAL_DATA_PTR;
@@ -32,34 +31,7 @@ int board_init(void)
#include
/* Enable early UART2 channel 1 on the RK322x */
#define GRF_BASE 0x1100
- struct rk322x_grf * const grf = (void *)GRF_BASE;
- enum {
- GPIO1B2_SHIFT = 4,
- GPIO1B2_MASK= 3 << GPIO1B2_SHIFT,
- GPIO1B2_GPIO= 0,
- GPIO1B2_UART21_SIN,
-
- GPIO1B1_SHIFT = 2,
- GPIO1B1_MASK= 3 << GPIO1B1_SHIFT,
- GPIO1B1_GPIO= 0,
- GPIO1B1_UART1_SOUT,
- GPIO1B1_UART21_SOUT,
- };
- enum {
- CON_IOMUX_UART2SEL_SHIFT= 8,
- CON_IOMUX_UART2SEL_MASK = 1 << CON_IOMUX_UART2SEL_SHIFT,
- CON_IOMUX_UART2SEL_2= 0,
- CON_IOMUX_UART2SEL_21,
- };
-
- rk_clrsetreg(&grf->gpio1b_iomux,
-GPIO1B1_MASK | GPIO1B2_MASK,
-GPIO1B2_UART21_SIN << GPIO1B2_SHIFT |
-GPIO1B1_UART21_SOUT << GPIO1B1_SHIFT);
- /* Set channel C as UART2 input */
- rk_clrsetreg(&grf->con_iomux,
-CON_IOMUX_UART2SEL_MASK,
-CON_IOMUX_UART2SEL_21 << CON_IOMUX_UART2SEL_SHIFT);
+ static struct rk322x_grf * const grf = (void *)GRF_BASE;
/*
* The integrated macphy is enabled by default, disable it
diff --git a/arch/arm/mach-rockchip/rk322x/Makefile
b/arch/arm/mach-rockchip/rk322x/Makefile
index ecb3e8dfda..89b0fed692 100644
--- a/arch/arm/mach-rockchip/rk322x/Makefile
+++ b/arch/arm/mach-rockchip/rk322x/Makefile
@@ -4,6 +4,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-
obj-y += clk_rk322x.o
+obj-y += rk322x.o
obj-y += syscon_rk322x.o
diff --git a/arch/arm/mach-rockchip/rk322x/rk322
[U-Boot] [PATCH v2 10/10] rockchip: rk3399: add board_debug_uart_init()
Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file for all rockchip SoCs later.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk3399-board-spl.c | 50 +--
arch/arm/mach-rockchip/rk3399/rk3399.c| 50 +++
2 files changed, 51 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399-board-spl.c
b/arch/arm/mach-rockchip/rk3399-board-spl.c
index 54a4b848a3..800ca80022 100644
--- a/arch/arm/mach-rockchip/rk3399-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3399-board-spl.c
@@ -127,53 +127,6 @@ void secure_timer_init(void)
writel(TIMER_EN | TIMER_FMODE, TIMER_CHN10_BASE + TIMER_CONTROL_REG);
}
-void board_debug_uart_init(void)
-{
-#define GRF_BASE 0xff77
-#define GPIO0_BASE 0xff72
-#define PMUGRF_BASE0xff32
- struct rk3399_grf_regs * const grf = (void *)GRF_BASE;
-#ifdef CONFIG_TARGET_CHROMEBOOK_BOB
- struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
- struct rockchip_gpio_regs * const gpio = (void *)GPIO0_BASE;
-#endif
-
-#if defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff18)
- /* Enable early UART0 on the RK3399 */
- rk_clrsetreg(&grf->gpio2c_iomux,
-GRF_GPIO2C0_SEL_MASK,
-GRF_UART0BT_SIN << GRF_GPIO2C0_SEL_SHIFT);
- rk_clrsetreg(&grf->gpio2c_iomux,
-GRF_GPIO2C1_SEL_MASK,
-GRF_UART0BT_SOUT << GRF_GPIO2C1_SEL_SHIFT);
-#else
-# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
- rk_setreg(&grf->io_vsel, 1 << 0);
-
- /*
-* Let's enable these power rails here, we are already running the SPI
-* Flash based code.
-*/
- spl_gpio_output(gpio, GPIO(BANK_B, 2), 1); /* PP1500_EN */
- spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_B, 2), GPIO_PULL_NORMAL);
-
- spl_gpio_output(gpio, GPIO(BANK_B, 4), 1); /* PP3000_EN */
- spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_B, 4), GPIO_PULL_NORMAL);
-#endif /* CONFIG_TARGET_CHROMEBOOK_BOB */
-
- /* Enable early UART2 channel C on the RK3399 */
- rk_clrsetreg(&grf->gpio4c_iomux,
-GRF_GPIO4C3_SEL_MASK,
-GRF_UART2DGBC_SIN << GRF_GPIO4C3_SEL_SHIFT);
- rk_clrsetreg(&grf->gpio4c_iomux,
-GRF_GPIO4C4_SEL_MASK,
-GRF_UART2DBGC_SOUT << GRF_GPIO4C4_SEL_SHIFT);
- /* Set channel C as UART2 input */
- rk_clrsetreg(&grf->soc_con7,
-GRF_UART_DBG_SEL_MASK,
-GRF_UART_DBG_SEL_C << GRF_UART_DBG_SEL_SHIFT);
-#endif
-}
void board_init_f(ulong dummy)
{
@@ -183,8 +136,7 @@ void board_init_f(ulong dummy)
struct rk3399_grf_regs *grf;
int ret;
-#define EARLY_UART
-#ifdef EARLY_UART
+#ifdef CONFIG_DEBUG_UART
debug_uart_init();
# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index b76ba4ed32..238f79a216 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -57,3 +57,53 @@ int arch_cpu_init(void)
return 0;
}
+
+#ifdef CONFIG_DEBUG_UART_BOARD_INIT
+void board_debug_uart_init(void)
+{
+#define GRF_BASE 0xff77
+#define GPIO0_BASE 0xff72
+#define PMUGRF_BASE0xff32
+ struct rk3399_grf_regs * const grf = (void *)GRF_BASE;
+#ifdef CONFIG_TARGET_CHROMEBOOK_BOB
+ struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
+ struct rockchip_gpio_regs * const gpio = (void *)GPIO0_BASE;
+#endif
+
+#if defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff18)
+ /* Enable early UART0 on the RK3399 */
+ rk_clrsetreg(&grf->gpio2c_iomux,
+GRF_GPIO2C0_SEL_MASK,
+GRF_UART0BT_SIN << GRF_GPIO2C0_SEL_SHIFT);
+ rk_clrsetreg(&grf->gpio2c_iomux,
+GRF_GPIO2C1_SEL_MASK,
+GRF_UART0BT_SOUT << GRF_GPIO2C1_SEL_SHIFT);
+#else
+# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
+ rk_setreg(&grf->io_vsel, 1 << 0);
+
+ /*
+* Let's enable these power rails here, we are already running the SPI
+* Flash based code.
+*/
+ spl_gpio_output(gpio, GPIO(BANK_B, 2), 1); /* PP1500_EN */
+ spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_B, 2), GPIO_PULL_NORMAL);
+
+ spl_gpio_output(gpio, GPIO(BANK_B, 4), 1); /* PP3000_EN */
+ spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_B, 4), GPIO_PULL_NORMAL);
+#endif /* CONFIG_TARGET_CHROMEBOOK_BOB */
+
+ /* Enable early UART2 channel C on the RK3399 */
+ rk_clrsetreg(&grf->gpio4c_iomux,
+GRF_GPIO4C3_SEL_MASK,
+GRF_UART2DGBC_SIN << GRF_GPIO4C3_SEL_SHIFT);
+ rk_clrsetreg(&grf->gpio4c_iomux,
+
[U-Boot] [PATCH v2 04/10] rockchip: rk3188: add board_debug_uart_init()
Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk3188-board-spl.c | 28 +-
arch/arm/mach-rockchip/rk3188/Makefile| 1 +
arch/arm/mach-rockchip/rk3188/rk3188.c| 36 +++
3 files changed, 38 insertions(+), 27 deletions(-)
create mode 100644 arch/arm/mach-rockchip/rk3188/rk3188.c
diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c
b/arch/arm/mach-rockchip/rk3188-board-spl.c
index 230d69c4c1..77b9b36d35 100644
--- a/arch/arm/mach-rockchip/rk3188-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3188-board-spl.c
@@ -93,38 +93,12 @@ static int setup_arm_clock(void)
return ret;
}
-void board_debug_uart_init(void)
-{
- /* Enable early UART on the RK3188 */
-#define GRF_BASE 0x20008000
- struct rk3188_grf * const grf = (void *)GRF_BASE;
- enum {
- GPIO1B1_SHIFT = 2,
- GPIO1B1_MASK= 3,
- GPIO1B1_GPIO= 0,
- GPIO1B1_UART2_SOUT,
-
- GPIO1B0_SHIFT = 0,
- GPIO1B0_MASK= 3,
- GPIO1B0_GPIO= 0,
- GPIO1B0_UART2_SIN,
- };
-
- /* Enable early UART on the RK3188 */
- rk_clrsetreg(&grf->gpio1b_iomux,
-GPIO1B1_MASK << GPIO1B1_SHIFT |
-GPIO1B0_MASK << GPIO1B0_SHIFT,
-GPIO1B1_UART2_SOUT << GPIO1B1_SHIFT |
-GPIO1B0_UART2_SIN << GPIO1B0_SHIFT);
-}
-
void board_init_f(ulong dummy)
{
struct udevice *dev;
int ret;
-#define EARLY_UART
-#ifdef EARLY_UART
+#ifdef CONFIG_DEBUG_UART
/*
* Debug UART can be used from here if required:
*
diff --git a/arch/arm/mach-rockchip/rk3188/Makefile
b/arch/arm/mach-rockchip/rk3188/Makefile
index 7fa010405b..7dc123a3d2 100644
--- a/arch/arm/mach-rockchip/rk3188/Makefile
+++ b/arch/arm/mach-rockchip/rk3188/Makefile
@@ -6,5 +6,6 @@
ifndef CONFIG_TPL_BUILD
obj-y += clk_rk3188.o
+obj-y += rk3188.o
obj-y += syscon_rk3188.o
endif
diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c
b/arch/arm/mach-rockchip/rk3188/rk3188.c
new file mode 100644
index 00..933484e0df
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 Rockchip Electronics Co., Ltd
+ */
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_DEBUG_UART_BOARD_INIT
+void board_debug_uart_init(void)
+{
+ /* Enable early UART on the RK3188 */
+#define GRF_BASE 0x20008000
+ struct rk3188_grf * const grf = (void *)GRF_BASE;
+ enum {
+ GPIO1B1_SHIFT = 2,
+ GPIO1B1_MASK= 3,
+ GPIO1B1_GPIO= 0,
+ GPIO1B1_UART2_SOUT,
+ GPIO1B1_JTAG_TDO,
+
+ GPIO1B0_SHIFT = 0,
+ GPIO1B0_MASK= 3,
+ GPIO1B0_GPIO= 0,
+ GPIO1B0_UART2_SIN,
+ GPIO1B0_JTAG_TDI,
+ };
+
+ rk_clrsetreg(&grf->gpio1b_iomux,
+GPIO1B1_MASK << GPIO1B1_SHIFT |
+GPIO1B0_MASK << GPIO1B0_SHIFT,
+GPIO1B1_UART2_SOUT << GPIO1B1_SHIFT |
+GPIO1B0_UART2_SIN << GPIO1B0_SHIFT);
+}
+#endif
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 07/10] rockchip: rk3288: add board_debug_uart_init()
Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file for all rockchip SoCs later.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk3288-board-spl.c | 12 ++--
arch/arm/mach-rockchip/rk3288-board-tpl.c | 16 ++--
arch/arm/mach-rockchip/rk3288/rk3288.c| 13 +
3 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index 937a99db53..d8d215db8a 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -109,16 +109,7 @@ void board_init_f(ulong dummy)
struct udevice *dev;
int ret;
- /* Example code showing how to enable the debug UART on RK3288 */
-#include
- /* Enable early UART on the RK3288 */
-#define GRF_BASE 0xff77
- struct rk3288_grf * const grf = (void *)GRF_BASE;
-
- rk_clrsetreg(&grf->gpio7ch_iomux, GPIO7C7_MASK << GPIO7C7_SHIFT |
-GPIO7C6_MASK << GPIO7C6_SHIFT,
-GPIO7C7_UART2DBG_SOUT << GPIO7C7_SHIFT |
-GPIO7C6_UART2DBG_SIN << GPIO7C6_SHIFT);
+#ifdef CONFIG_DEBUG_UART
/*
* Debug UART can be used from here if required:
*
@@ -129,6 +120,7 @@ void board_init_f(ulong dummy)
*/
debug_uart_init();
debug("\nspl:debug uart enabled in %s\n", __func__);
+#endif
ret = spl_early_init();
if (ret) {
debug("spl_early_init() failed: %d\n", ret);
diff --git a/arch/arm/mach-rockchip/rk3288-board-tpl.c
b/arch/arm/mach-rockchip/rk3288-board-tpl.c
index a430bb43ad..a9848067ba 100644
--- a/arch/arm/mach-rockchip/rk3288-board-tpl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-tpl.c
@@ -10,28 +10,16 @@
#include
#include
#include
-#include
#include
-#include
-#include
-#include
#include
#include
-#define GRF_BASE 0xff77
void board_init_f(ulong dummy)
{
struct udevice *dev;
int ret;
- /* Example code showing how to enable the debug UART on RK3288 */
- /* Enable early UART on the RK3288 */
- struct rk3288_grf * const grf = (void *)GRF_BASE;
-
- rk_clrsetreg(&grf->gpio7ch_iomux, GPIO7C7_MASK << GPIO7C7_SHIFT |
-GPIO7C6_MASK << GPIO7C6_SHIFT,
-GPIO7C7_UART2DBG_SOUT << GPIO7C7_SHIFT |
-GPIO7C6_UART2DBG_SIN << GPIO7C6_SHIFT);
+#ifdef CONFIG_DEBUG_UART
/*
* Debug UART can be used from here if required:
*
@@ -41,7 +29,7 @@ void board_init_f(ulong dummy)
* printascii("string");
*/
debug_uart_init();
-
+#endif
ret = spl_early_init();
if (ret) {
debug("spl_early_init() failed: %d\n", ret);
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index 987fae544c..7941ca68a6 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -18,3 +18,16 @@ int arch_cpu_init(void)
return 0;
}
+
+#ifdef CONFIG_DEBUG_UART_BOARD_INIT
+void board_debug_uart_init(void)
+{
+ /* Enable early UART on the RK3288 */
+ struct rk3288_grf * const grf = (void *)GRF_BASE;
+
+ rk_clrsetreg(&grf->gpio7ch_iomux, GPIO7C7_MASK << GPIO7C7_SHIFT |
+GPIO7C6_MASK << GPIO7C6_SHIFT,
+GPIO7C7_UART2DBG_SOUT << GPIO7C7_SHIFT |
+GPIO7C6_UART2DBG_SIN << GPIO7C6_SHIFT);
+}
+#endif
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/10] rockchip: rk3399: use grf structure to access reg
Prefer to use structure to access register if we could.
Signed-off-by: Kever Yang
---
arch/arm/mach-rockchip/rk3399/rk3399.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 7567a4f584..b76ba4ed32 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -6,11 +6,13 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
#define GRF_EMMCCORE_CON11 0xff77f02c
+#define GRF_BASE 0xff77
static struct mm_region rk3399_mem_map[] = {
{
@@ -48,9 +50,10 @@ int dram_init_banksize(void)
int arch_cpu_init(void)
{
/* We do some SoC one time setting here. */
+ struct rk3399_grf_regs * const grf = (void *)GRF_BASE;
/* Emmc clock generator: disable the clock multipilier */
- rk_clrreg(GRF_EMMCCORE_CON11, 0x0ff);
+ rk_clrreg(&grf->emmccore_con[11], 0x0ff);
return 0;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Tue, Mar 26, 2019 at 06:43:52PM +0100, Marek Vasut wrote: > Various fixes for bugs found by u-boot test.py > > The following changes since commit cfb3e102c4bdf96a41cbd3eeb1d3a9a56c69c46c: > > Merge branch '2019-03-22-master-imports' (2019-03-22 19:09:58 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to c453fe3a0513f758c7d0b580307909637eb31c9f: > > mmc: tmio: Clamp SD_SECCNT to 16bit values on 16bit IP (2019-03-25 > 20:26:53 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Tue, Mar 26, 2019 at 06:44:14PM +0100, Marek Vasut wrote: > The following changes since commit cfb3e102c4bdf96a41cbd3eeb1d3a9a56c69c46c: > > Merge branch '2019-03-22-master-imports' (2019-03-22 19:09:58 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to 3d0cc01d101abc3efd5feabe85f22a42ebcbcca2: > > configs: Stratix10: Remove CONFIG_USE_TINY_PRINTF (2019-03-25 20:26:45 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] doc/git-mailrc: correct entry 'agraf'
> Am 29.03.2019 um 05:51 schrieb Heinrich Schuchardt : > > Correct Alex's email address. > > Signed-off-by: Heinrich Schuchardt Thanks! Reviewed-by: Alexander Graf Alex > --- > doc/git-mailrc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/git-mailrc b/doc/git-mailrc > index c2eee8c7d8..b75ebab02b 100644 > --- a/doc/git-mailrc > +++ b/doc/git-mailrc > @@ -15,7 +15,7 @@ alias abiessmann Andreas Bießmann > > alias abrodkin Alexey Brodkin > alias afleming Andy Fleming > alias ag Anatolij Gustschin > -alias agraf Alexander Graf > +alias agraf Alexander Graf > alias alisonwang Alison Wang > alias angelo_ts Angelo Dureghello > alias bmeng Bin Meng > -- > 2.20.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull ARC last minute changes for 2019.04
On Thu, Mar 28, 2019 at 07:53:36AM +, Alexey Brodkin wrote: > Hi Tom, > > The following changes since commit 2b9b9cdd5f9ae1cbc786ba3c2255a51b3ea4a636: > > Merge branch '2019-03-25-master-imports' (2019-03-26 23:17:21 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-arc.git tags/arc-last-minute-for-2019.04 > > for you to fetch changes up to 34d117b1fb055920e742baafdd9c1a390c480519: > > hsdk: readme: Suggest getting pyelftools with pip (2019-03-28 10:50:32 > +0300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request for UEFI system for v2019.04-rc5-2
The following changes since commit 2b9b9cdd5f9ae1cbc786ba3c2255a51b3ea4a636: Merge branch '2019-03-25-master-imports' (2019-03-26 23:17:21 -0400) are available in the Git repository at: https://git.denx.de/u-boot-efi.git tags/efi-2019-04-rc5-2 for you to fetch changes up to 9ba712dc84e8824055c368a385794f69aabab661: efi_loader: define development target in README.uefi (2019-03-28 08:13:00 +0100) Travis CI: https://travis-ci.org/xypron2/u-boot/builds/512697352 Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 Pull request for UEFI system for v2019.04-rc5-2 This patch series contains a bug fix for a double free in a UEFI unit test. The other patches are documentation only (except for the definition of two additional constants). Heinrich Schuchardt (5): efi_selftest: avoid double free in dp utilities test efi_loader: TODO for the EFI file protocol MAINTAINERS: adjust git repository for EFI PAYLOAD efi_loader: update TODOs in doc/README.uefi efi_loader: define development target in README.uefi MAINTAINERS | 2 +- doc/README.uefi | 19 +++ include/efi_api.h | 8 +++- lib/efi_loader/efi_file.c | 4 lib/efi_selftest/efi_selftest_devicepath_util.c | 5 - 5 files changed, 27 insertions(+), 11 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
