Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
Dear Tom Rini, In message <20180224215325.GQ4311@bill-the-cat> you wrote: > > > Why do you ignore this NAK, and why do you add this patch so late in > > the release cycle anyway? > > Sorry, didn't v2 address your concerns? We don't initialize the device > because maybe we'll have env there, we initalize mmc because we need to > check that it is there. Thanks! No, it does not. As is, we initialize MMC in the EXT4 code (in env_ext4_load()). If we go that route, we would have to add similar init calls to all other file systemn load routines as well. This does not make sense to me. This pollutes the code with unrelated things - file system code should not depend on any underlaying driver suport. It increases code size, makes the code harder to maintain (if you need to change this, there is good chances to forget the same change in other file systems), and there is a good chance that in the end you will initialzie MMC even if you don't use it. We should keep the code clean and orthogonal. Driver init code has no place in file system code. If needed, the drivers have to make sure to auto--initialize on first access. I hold my NAK on this patch. It is the wrong thing to do. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A meeting is an event at which the minutes are kept and the hours are lost. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Interface changes for adding TCP
Dear Duncan, In message <20180224223615.14584-1...@synoia.com> you wrote: > > This code has passed through patman. Oh, do you really think this is a good description of what this patch does? You can do better, I bet. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Faith may be defined briefly as an illogical belief in the occurence of the improbable.- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] core: do not fail in device_probe() when clk set default fail
Assigned clocks are widely used in kernel, but not in U-Boot yet, many U-Boot clock driver do not have the API while dts port from kernel have "assigned-clocks" node. Just give a warning now instead of a device probe fail. Signed-off-by: Kever Yang --- drivers/core/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/core/device.c b/drivers/core/device.c index 9d58f44..71872e9 100644 --- a/drivers/core/device.c +++ b/drivers/core/device.c @@ -407,7 +407,7 @@ int device_probe(struct udevice *dev) /* Process 'assigned-{clocks/clock-parents/clock-rates}' properties */ ret = clk_set_defaults(dev); if (ret) - goto fail; + debug("%s clk_set_defaults failed %d\n", ret); if (drv->probe) { ret = drv->probe(dev); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR
Hi Tom, > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig. We can > provide a default for BOOTCOUNT_AM33XX as that's a specific part of > the RTC in use. We can also provide a default for ARCH_LS1043A and > ARCH_LS1021A as they had been previously calculated and their symbols > are in Kconfig. In the case of other QE-enabled platforms, they are > not so we must update the relevant defconfig files. The previous > default only applied in some cases, even on a specific SoC family. Thanks for your patch. I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig. Please correct me if I'm wrong, but it shall be applied on top of Alex's series: http://patchwork.ozlabs.org/cover/874539/ Reviewed-by: Lukasz Majewski > > Signed-off-by: Tom Rini > --- > configs/calimain_defconfig | 1 + > configs/dh_imx6_defconfig | 1 + > configs/ge_b450v3_defconfig | 1 + > configs/ge_b650v3_defconfig | 1 + > configs/ge_b850v3_defconfig | 1 + > configs/highbank_defconfig | 1 + > configs/ids8313_defconfig | 1 + > configs/kmcoge4_defconfig | 1 + > configs/kmcoge5ne_defconfig | 1 + > configs/kmeter1_defconfig | 1 + > configs/kmlion1_defconfig | 1 + > configs/kmopti2_defconfig | 1 + > configs/kmsupx5_defconfig | 1 + > configs/kmtegr1_defconfig | 1 + > configs/kmtepr2_defconfig | 1 + > configs/kmvect1_defconfig | 1 + > configs/mx53ppd_defconfig | 1 + > configs/socfpga_is1_defconfig | 1 + > configs/socfpga_sr1500_defconfig| 1 + > configs/suvd3_defconfig | 1 + > configs/tqma6s_wru4_mmc_defconfig | 1 + > configs/tuge1_defconfig | 1 + > configs/tuxx1_defconfig | 1 + > configs/x600_defconfig | 1 + > drivers/bootcount/Kconfig | 6 -- > drivers/bootcount/bootcount.c | 16 > include/configs/brppt1.h| 3 --- > include/configs/calimain.h | 1 - > include/configs/dh_imx6.h | 1 - > include/configs/ge_bx50v3.h | 2 -- > include/configs/highbank.h | 1 - > include/configs/ids8313.h | 3 --- > include/configs/km/kmp204x-common.h | 3 --- > include/configs/socfpga_is1.h | 2 -- > include/configs/socfpga_sr1500.h| 2 -- > include/configs/ti_am335x_common.h | 7 --- > include/configs/tqma6_wru4.h| 1 - > include/configs/x600.h | 4 > 38 files changed, 28 insertions(+), 48 deletions(-) > > diff --git a/configs/calimain_defconfig b/configs/calimain_defconfig > index cbb31f6bf321..234b1a593567 100644 > --- a/configs/calimain_defconfig > +++ b/configs/calimain_defconfig > @@ -23,6 +23,7 @@ CONFIG_CMD_DIAG=y > CONFIG_ENV_IS_IN_FLASH=y > CONFIG_BOOTP_DNS=y > CONFIG_BOOTCOUNT_LIMIT=y > +CONFIG_SYS_BOOTCOUNT_ADDR=0x01C23000 > # CONFIG_MMC is not set > CONFIG_MTD_NOR_FLASH=y > CONFIG_SYS_NS16550=y > diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig > index 251fcd01b69a..2b4fe9c2c596 100644 > --- a/configs/dh_imx6_defconfig > +++ b/configs/dh_imx6_defconfig > @@ -35,6 +35,7 @@ CONFIG_CMD_EXT4_WRITE=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_DWC_AHSATA=y > CONFIG_BOOTCOUNT_LIMIT=y > +CONFIG_SYS_BOOTCOUNT_ADDR=0x0090 > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_SPANSION=y > CONFIG_PHYLIB=y > diff --git a/configs/ge_b450v3_defconfig b/configs/ge_b450v3_defconfig > index ee1cc432e0e0..045380b6de8e 100644 > --- a/configs/ge_b450v3_defconfig > +++ b/configs/ge_b450v3_defconfig > @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_BOOTCOUNT_LIMIT=y > CONFIG_BOOTCOUNT_EXT=y > CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5" > +CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000 > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_NETDEVICES=y > diff --git a/configs/ge_b650v3_defconfig b/configs/ge_b650v3_defconfig > index 27a89b0be782..9d4b8aeebedc 100644 > --- a/configs/ge_b650v3_defconfig > +++ b/configs/ge_b650v3_defconfig > @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_BOOTCOUNT_LIMIT=y > CONFIG_BOOTCOUNT_EXT=y > CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5" > +CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000 > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_NETDEVICES=y > diff --git a/configs/ge_b850v3_defconfig b/configs/ge_b850v3_defconfig > index af4ba9754331..94785681be7d 100644 > --- a/configs/ge_b850v3_defconfig > +++ b/configs/ge_b850v3_defconfig > @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_BOOTCOUNT_LIMIT=y > CONFIG_BOOTCOUNT_EXT=y > CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5" > +CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000 > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_NETDEVICES=y > diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig > index 7b9c0e7d4770..55f83ed1e17c 100644 > --- a/configs/highbank_defconfig > +++ b/configs/highbank_defconfig > @@ -17,6
[U-Boot] [PULL] Please pull u-boot-rockchip/master
Tom, we have additional fixes ready for you: * the TPL-build process for the Vyasa board was fixed by Jagan (by providing the correct TEXT_BASE) * a regression on Ethernet for the RK3399 and RK3368 has been resolved by adding support for its clocks * a regression on PMIC probing on the RK399 has been resolved by adding support for the assigned-clocks of the PMUCRU Travis report is at https://travis-ci.org/ptomsich/u-boot-rockchip/builds/345699336 Thanks, Philipp. The following changes since commit 0bb430c8494e26e8d258cf6957cdd39d2ce4f309: Merge git://git.denx.de/u-boot-video (2018-02-24 08:02:17 -0500) are available in the git repository at: git://git.denx.de/u-boot-rockchip.git master for you to fetch changes up to 434d5a00a4578f826e7e2cef29bf2388dd760a88: rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL (2018-02-24 18:50:03 +0100) Jagan Teki (2): rockchip: rk3288: Add TPL_LDSCRIPT rockchip: rk3288: Fix wrong TPL_TEXT_BASE Philipp Tomsich (3): rockchip: clk: rk3399: handle clk_enable requests for GMAC rockchip: clk: rk3368: handle clk_enable requests for GMAC rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL arch/arm/mach-rockchip/Kconfig | 10 ++ arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++ configs/vyasa-rk3288_defconfig | 1 - drivers/clk/rockchip/clk_rk3368.c| 19 +++ drivers/clk/rockchip/clk_rk3399.c| 19 +++ 5 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] core: do not fail in device_probe() when clk set default fail
> On 25 Feb 2018, at 11:24, Kever Yang wrote: > > Assigned clocks are widely used in kernel, but not in U-Boot yet, > many U-Boot clock driver do not have the API while dts port from kernel > have "assigned-clocks" node. > > Just give a warning now instead of a device probe fail. I strongly disagree on this one: the only reason this can fail is if assigned-clock-rates can not be set (e.g. because a clock that should be assigned to is not known by the clock driver). However, this should never be ignored silently. If the clock subsystem does not know all clocks that are being attempted to set, then commits to shared drivers will eventually break: e.g. commit ba1f96672522 ("net: designware: add clock support”) recently broke the GMAC for the RK3368 and RK3399 because it iterated over all clocks defined in the “clocks” property of the GMAC node. As long as various drivers perform an unconditional clk_enable and/or an unconditional clk_set_rate, we should enforce this in the core already. In consequence, dedicated code from the drivers should now start to slowly disappear, as clock-rates can now be set via the DTS. > > Signed-off-by: Kever Yang > --- > > drivers/core/device.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/core/device.c b/drivers/core/device.c > index 9d58f44..71872e9 100644 > --- a/drivers/core/device.c > +++ b/drivers/core/device.c > @@ -407,7 +407,7 @@ int device_probe(struct udevice *dev) > /* Process 'assigned-{clocks/clock-parents/clock-rates}' properties */ > ret = clk_set_defaults(dev); > if (ret) > - goto fail; > + debug("%s clk_set_defaults failed %d\n", ret); This probably shouldn’t have been a silent failure. A pr_err() may be more appropriate… I would recommend this to continue failing though, as it is simple enough to handle the additional clocks in the clock drivers and create a permanent record of “things not needing additional changes, due to the BROM already having set up things” by returning success. > > if (drv->probe) { > ret = drv->probe(dev); > -- > 1.9.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi
Hi! Thanks for confirming this! I see four ways how this can be solved: 1. I can locally adjust the memory locations to make my > 16MiB kernel work. The commit mentioned by Jaehoon Chung does this via a custom boot.scr, I did this by bumping $scriptaddr and $ramdisk_addr_r interactively during bootup and storing the changes to the Micro SD card with the "saveenv" command. 2. I could place a "uEnv.txt on the Micro SD card with those bumped values in it. This would make this work-around deployable via Puppet, but unfortunately reading "uEnv.txt" on bootup seems to be a board-specific feature, and the RPI code currently doesn't seem to have this feature. [0] 3. I could ask Debian to patch the upstream default values for these memory locations. After all, a distro bootloader which doesn't boot the distro kernel is pretty useless, so I imagine they would probably consider this. 4. U-Boot upstream could adjust the memory locations themselves. I would be happy to submit a patch for this, however I want get some feedback first: Would you guys accept such a patch, bumping the supported kernel size to e.g. 32 MiB or even 64 MiB? I would prefer 4>3>2>1, what do you think? Best regards Alexander Kurtz [0] https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR
On Sun, Feb 25, 2018 at 11:29:30AM +0100, Lukasz Majewski wrote: > Hi Tom, > > > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig. We can > > provide a default for BOOTCOUNT_AM33XX as that's a specific part of > > the RTC in use. We can also provide a default for ARCH_LS1043A and > > ARCH_LS1021A as they had been previously calculated and their symbols > > are in Kconfig. In the case of other QE-enabled platforms, they are > > not so we must update the relevant defconfig files. The previous > > default only applied in some cases, even on a specific SoC family. > > Thanks for your patch. > > I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig. > > Please correct me if I'm wrong, but it shall be applied on top of > Alex's series: > > http://patchwork.ozlabs.org/cover/874539/ Correct. I tested that and the only part I wasn't 100% confident in after transition was the addresses. -- 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] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
On Sun, Feb 25, 2018 at 09:53:10AM +0100, Wolfgang Denk wrote: > Dear Tom Rini, > > In message <20180224215325.GQ4311@bill-the-cat> you wrote: > > > > > Why do you ignore this NAK, and why do you add this patch so late in > > > the release cycle anyway? > > > > Sorry, didn't v2 address your concerns? We don't initialize the device > > because maybe we'll have env there, we initalize mmc because we need to > > check that it is there. Thanks! > > No, it does not. As is, we initialize MMC in the EXT4 code (in > env_ext4_load()). If we go that route, we would have to add similar > init calls to all other file systemn load routines as well. > > This does not make sense to me. This pollutes the code with > unrelated things - file system code should not depend on any > underlaying driver suport. It increases code size, makes the code > harder to maintain (if you need to change this, there is good > chances to forget the same change in other file systems), and there > is a good chance that in the end you will initialzie MMC even if you > don't use it. > > We should keep the code clean and orthogonal. Driver init code has > no place in file system code. > > If needed, the drivers have to make sure to auto--initialize on > first access. > > I hold my NAK on this patch. It is the wrong thing to do. I think you have this a little bit wrong. But, it's also where we are with the DM conversion. This _is_ the first place we're trying to access the MMC. And it's not in the filesystem code, it's in the environment code. That said, Faiz, what exactly is the failure sequence (and hardware)? 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] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
Dear Tom, In message <20180225134810.GU4311@bill-the-cat> you wrote: > > > We should keep the code clean and orthogonal. Driver init code has > > no place in file system code. > > > > If needed, the drivers have to make sure to auto--initialize on > > first access. > > > > I hold my NAK on this patch. It is the wrong thing to do. > > I think you have this a little bit wrong. But, it's also where we are > with the DM conversion. This _is_ the first place we're trying to > access the MMC. And it's not in the filesystem code, it's in the > environment code. Maybe I was not really clear. You are right as this is not generic file system code. Instead, it is the EXT4 support code for the environment handling. The patch adds mmc_initialize() to env_ext4_load(), so whenever we try to load the environment from an EXT4 file system, it will initialize the MMC subsystem. However - what if we want to load the environment from an EXT4 file system on any other storage device - say, USB, or SATA, or flash? In all such cases the initialization of MMC would be plain wrong. And what if we want to load the environment from any other type of file system - say, cramfs, zfs, etc. - on SDCard or eMMC? These do not initialize MMC, so it would fail? Yes, we have the same crappy code in env/fat.c, but this is the wrong thing to do, and must be cleaned up there as well. This is what I meant when I wrote that the file system (interface) code and the storage device support code are independent of each other, and code should be kept orthogonal - storage support like MMC etc. has no place in code dealing with a specific file system type. I still think my NAK is reasonable. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
Hi Tom, Wolfgang, > On Sun, Feb 25, 2018 at 09:53:10AM +0100, Wolfgang Denk wrote: > > Dear Tom Rini, > > > > In message <20180224215325.GQ4311@bill-the-cat> you wrote: > > > > > > > Why do you ignore this NAK, and why do you add this patch so > > > > late in the release cycle anyway? > > > > > > Sorry, didn't v2 address your concerns? We don't initialize the > > > device because maybe we'll have env there, we initalize mmc > > > because we need to check that it is there. Thanks! > > > > No, it does not. As is, we initialize MMC in the EXT4 code (in > > env_ext4_load()). If we go that route, we would have to add similar > > init calls to all other file systemn load routines as well. > > > > This does not make sense to me. This pollutes the code with > > unrelated things - file system code should not depend on any > > underlaying driver suport. It increases code size, makes the code > > harder to maintain (if you need to change this, there is good > > chances to forget the same change in other file systems), and there > > is a good chance that in the end you will initialzie MMC even if you > > don't use it. > > > > We should keep the code clean and orthogonal. Driver init code has > > no place in file system code. > > > > If needed, the drivers have to make sure to auto--initialize on > > first access. > > > > I hold my NAK on this patch. It is the wrong thing to do. > > I think you have this a little bit wrong. But, it's also where we are > with the DM conversion. This _is_ the first place we're trying to > access the MMC. And it's not in the filesystem code, it's in the > environment code. > > That said, Faiz, what exactly is the failure sequence (and hardware)? As I've read the discussion between Tom and Wolfgang - I'm wondering if this initialization could be done in the driver model? I think that DM is a right place to put such code (ecluding the case of env in eMMC readed in SPL). I've added Simon to CC, so maybe he can give us some insights. > Thanks! > 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-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgpnqt0QigjiZ.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/2] rockchip: rk3288: Fix wrong TPL_TEXT_BASE
> TPL offset 0xff704004 is unaligned address which is adding nearest > 8-bytes for next instruction, So 0xff704004 is adding 0x20 for > proper alignment which is causing the next instruction data > 0xefff is moved. > > Hexdump with overlaped bytes: > - > 000 > 010 eaff > > So, Fix the TEXT_BASE for proper aligned address 0xff704000 > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > --- > Changes for v2: > - Update commit message > > arch/arm/mach-rockchip/Kconfig | 3 +++ > configs/vyasa-rk3288_defconfig | 1 - > 2 files changed, 3 insertions(+), 1 deletion(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,1/2] rockchip: rk3288: Add TPL_LDSCRIPT
> Due to size limitations in SPL by adding falcon mode, > rk3288 support TPL. In order to not overlap SPL_TEXT_BASE > add TPL_TEXT_BASE with u-boot-tpl.lds that intern call > u-boot-spl.lds with proper TEXT_BASE values. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > --- > Changes for v2: > - none > > arch/arm/mach-rockchip/Kconfig | 7 +++ > arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++ > 2 files changed, 17 insertions(+) > create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL
> The device-tree node for the PMU clk controller assigns to its parent > (i.e. PLL_PPLL) even though this clock currently is set up statically > by an init-function. > > In order to avoid unexpected failures, a simple implementation of > set_rate (which accepts requests, but notifies the caller of the > preset frequency in its return value) and get_rate (which always > returns the preset frequency) are added. > > Note that this is required for the RK808 PMIC to probe successfully on > the RK3399-Q7, following the support for the assigned-clocks property. > > References: commit f4fcba5c5baa ("clk: implement clk_set_defaults()") > Signed-off-by: Philipp Tomsich > Tested-by: Klaus Goger > --- > > drivers/clk/rockchip/clk_rk3399.c | 9 + > 1 file changed, 9 insertions(+) > > 2.1.4 > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,9/9] rk3288: vyasa: Add eMMC boot support
> RK3288 Vyasa has eMMC boot support, with JP4 open. > > Signed-off-by: Jagan Teki > --- > Note: > Linux patch for this support is in ML. > > arch/arm/dts/rk3288-vyasa-u-boot.dtsi | 4 > arch/arm/dts/rk3288-vyasa.dts | 11 +++ > board/amarula/vyasa-rk3288/vyasa-rk3288.c | 7 +++ > 3 files changed, 22 insertions(+) > Acked-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 5/9] ARM: dts: rockchip: Add gmac support for rk3288-vyasa board
> Sync gmac dts node from Linux. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Signed-off-by: Jagan Teki > --- > arch/arm/dts/rk3288-vyasa.dts | 41 + > 1 file changed, 41 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,9/9] rk3288: vyasa: Add eMMC boot support
> RK3288 Vyasa has eMMC boot support, with JP4 open. > > Signed-off-by: Jagan Teki > --- > Note: > Linux patch for this support is in ML. > > arch/arm/dts/rk3288-vyasa-u-boot.dtsi | 4 > arch/arm/dts/rk3288-vyasa.dts | 11 +++ > board/amarula/vyasa-rk3288/vyasa-rk3288.c | 7 +++ > 3 files changed, 22 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] core: add uclass_get_device_by_phandle_id() api
Hi Kever, On 23 February 2018 at 19:08, Kever Yang wrote: > Hi Simon, > > > On 02/12/2018 10:35 PM, Simon Glass wrote: >> Hi Kever, >> >> On 8 February 2018 at 19:56, Kever Yang wrote: >>> Add api for who can not get phandle from a device property. >> Can you please add a motivation to the commit message? It is not >> obvious to me when this function would be used. > Here is the example why I need this, see the dts node here: > lvds@ff2e { > ... > rockchip,grf = <&grf>; > port { > port@0 { > endpoint@0 { > remote-endpoint = <&vopl_out_lvds>; > } > } > } > } > > We can only get 'grf' udevice by uclass_get_device_by_phandle(), > but we not able to get udevice 'vopl_out_lvds', other driver like > rockchip pinctrl > also need to get udevice by a phandle which is not one of direct property of > another device node. OK I see. This sort of info is useful in the commit message. It helps to know two things about a patch: - why it is needed - what it does In this case see rk_display_init() for how it handles the 'remote-endpoint' property. I think it would be better to have something like: ofnode ofnode_lookup_phandle(ofnode node, const char *prop_name); This should meet your needs without needing to decoding the phandle property in the caller. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: dts: imx6ul: add wdog3
The i.MX6UL has a WDOG3 located at start address 0x021E in the AIPS-2 memory region [1]. [1] i.MX 6UltraLite Applications Processor Reference Manual, Rev. 1, 04/2016, Table-2-3 AIPS-2 memory map, p. 166 Signed-off-by: Jörg Krause --- arch/arm/dts/imx6ul.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/dts/imx6ul.dtsi b/arch/arm/dts/imx6ul.dtsi index 7affab866f..b63f5a53ac 100644 --- a/arch/arm/dts/imx6ul.dtsi +++ b/arch/arm/dts/imx6ul.dtsi @@ -881,6 +881,14 @@ status = "disabled"; }; + wdog3: wdog@021e4000 { + compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt"; + reg = <0x021e4000 0x4000>; + interrupts = ; + clocks = <&clks IMX6UL_CLK_WDOG3>; + status = "disabled"; + }; + uart2: serial@021e8000 { compatible = "fsl,imx6ul-uart", "fsl,imx6q-uart"; -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: dts: imx6ull: add wdog3
The i.MX6ULL has a WDOG3 located at start address 0x021E in the AIPS-2 memory region [1]. [1] i.MX 6ULL Applications Processor Reference Manual, Rev. 1, 11/2017, Table 2-3. AIPS-2 memory map, p. 178 Signed-off-by: Jörg Krause --- arch/arm/dts/imx6ull.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/dts/imx6ull.dtsi b/arch/arm/dts/imx6ull.dtsi index 28b8422f31..f8ec649460 100644 --- a/arch/arm/dts/imx6ull.dtsi +++ b/arch/arm/dts/imx6ull.dtsi @@ -1026,6 +1026,14 @@ status = "disabled"; }; + wdog3: wdog@021e4000 { + compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt"; + reg = <0x021e4000 0x4000>; + interrupts = ; + clocks = <&clks IMX6UL_CLK_WDOG3>; + status = "disabled"; + }; + uart2: serial@021e8000 { compatible = "fsl,imx6ul-uart", "fsl,imx6q-uart", "fsl,imx21-uart"; -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
Dear Lukasz, In message <20180225161813.10554012@jawa> you wrote: > > As I've read the discussion between Tom and Wolfgang - I'm wondering if > this initialization could be done in the driver model? Indeed DM would be a good place for such lazy initialization as would be useful here. > > I think that DM is a right place to put such code (ecluding the case > of env in eMMC readed in SPL). But even there we cannot add code to initialize all kinds of potential storage devices to all kinds of supported file systems. This may work with a single fixed configuration (which probably is what the OP had in mind), but it does not scale, and it is the wrong thing to do. > I've added Simon to CC, so maybe he can give us some insights. Thanks. Hopefully Simon has a clever idea... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "If you can, help others. If you can't, at least don't hurt others." - the Dalai Lama ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR
On Sun, Feb 25, 2018 at 1:23 PM, Tom Rini wrote: > On Sun, Feb 25, 2018 at 11:29:30AM +0100, Lukasz Majewski wrote: >> Hi Tom, >> >> > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig. We can >> > provide a default for BOOTCOUNT_AM33XX as that's a specific part of >> > the RTC in use. We can also provide a default for ARCH_LS1043A and >> > ARCH_LS1021A as they had been previously calculated and their symbols >> > are in Kconfig. In the case of other QE-enabled platforms, they are >> > not so we must update the relevant defconfig files. The previous >> > default only applied in some cases, even on a specific SoC family. >> >> Thanks for your patch. >> >> I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig. >> >> Please correct me if I'm wrong, but it shall be applied on top of >> Alex's series: >> >> http://patchwork.ozlabs.org/cover/874539/ > > Correct. I tested that and the only part I wasn't 100% confident in > after transition was the addresses. > Having looked at it both ways (migrate CONFIG_SYS_BOOTCOUNT_ADDR into Kconfig, migrate everything out of the CONFIG_ namespace) they both seem to have downsides... either you have magic numbers in Kconfig or you have configuration littered through include files. It feels like it wants some piece of machinery we don't really have today. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR
On Sun, Feb 25, 2018 at 3:50 AM, Tom Rini wrote: > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig. We can > provide a default for BOOTCOUNT_AM33XX as that's a specific part of the > RTC in use. We can also provide a default for ARCH_LS1043A and > ARCH_LS1021A as they had been previously calculated and their symbols > are in Kconfig. In the case of other QE-enabled platforms, they are not > so we must update the relevant defconfig files. The previous default > only applied in some cases, even on a specific SoC family. > > Signed-off-by: Tom Rini Reviewed-by: Alex Kiernan -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
On Sun, Feb 25, 2018 at 03:50:41PM +0100, Wolfgang Denk wrote: > Dear Tom, > > In message <20180225134810.GU4311@bill-the-cat> you wrote: > > > > > We should keep the code clean and orthogonal. Driver init code has > > > no place in file system code. > > > > > > If needed, the drivers have to make sure to auto--initialize on > > > first access. > > > > > > I hold my NAK on this patch. It is the wrong thing to do. > > > > I think you have this a little bit wrong. But, it's also where we are > > with the DM conversion. This _is_ the first place we're trying to > > access the MMC. And it's not in the filesystem code, it's in the > > environment code. > > Maybe I was not really clear. You are right as this is not generic > file system code. Instead, it is the EXT4 support code for the > environment handling. > > The patch adds mmc_initialize() to env_ext4_load(), so whenever we > try to load the environment from an EXT4 file system, it will > initialize the MMC subsystem. > > However - what if we want to load the environment from an EXT4 file > system on any other storage device - say, USB, or SATA, or flash? Good question, and part of why after re-reading the code, I want to see just what the combination of hardware Faiz is trying is. MMC should already have been initialized. Unless I'm missing the specific init path he has. This does also highlight that env on fat/ext4 as only likely been tested on MMC devices, even prior to the recent changes. > In all such cases the initialization of MMC would be plain wrong. Correct, and we don't try and initialize MMC if we aren't told that the environment resides on mmc. > And what if we want to load the environment from any other type of > file system - say, cramfs, zfs, etc. - on SDCard or eMMC? These do > not initialize MMC, so it would fail? > > Yes, we have the same crappy code in env/fat.c, but this is the > wrong thing to do, and must be cleaned up there as well. Yes, one of the things I've suggested before is that ENV_IS_IN_FAT and ENV_IS_IN_EXT should be able to be rewritten to use the generic FS operation API we have so that zfs, etc, could be automatically supported. > This is what I meant when I wrote that the file system (interface) > code and the storage device support code are independent of each > other, and code should be kept orthogonal - storage support like MMC > etc. has no place in code dealing with a specific file system type. The problem we have today, and I hope we can more cleverly resolve once more/everything has been migrated to DM is that don't yet have a good way to say "retry $X later" or "retry $X after $Y". Because setting aside the specific issue Faiz ran into, FS+SATA has never worked because initr_scsi is well after initr_env, and that's why the sata env code (which uses blocks and not fs) has always had to sata_initialize(). > I still think my NAK is reasonable. Conceptually, I disagree because we don't yet have a more nicer solution available yet. With this specific patch, it might be a problem with the board code, as mmc_initialize() should already have been called. So maybe this needs to come out. -- 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] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR
On Sun, Feb 25, 2018 at 05:44:42PM +, Alex Kiernan wrote: > On Sun, Feb 25, 2018 at 1:23 PM, Tom Rini wrote: > > On Sun, Feb 25, 2018 at 11:29:30AM +0100, Lukasz Majewski wrote: > >> Hi Tom, > >> > >> > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig. We can > >> > provide a default for BOOTCOUNT_AM33XX as that's a specific part of > >> > the RTC in use. We can also provide a default for ARCH_LS1043A and > >> > ARCH_LS1021A as they had been previously calculated and their symbols > >> > are in Kconfig. In the case of other QE-enabled platforms, they are > >> > not so we must update the relevant defconfig files. The previous > >> > default only applied in some cases, even on a specific SoC family. > >> > >> Thanks for your patch. > >> > >> I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig. > >> > >> Please correct me if I'm wrong, but it shall be applied on top of > >> Alex's series: > >> > >> http://patchwork.ozlabs.org/cover/874539/ > > > > Correct. I tested that and the only part I wasn't 100% confident in > > after transition was the addresses. > > > > Having looked at it both ways (migrate CONFIG_SYS_BOOTCOUNT_ADDR into > Kconfig, migrate everything out of the CONFIG_ namespace) they both > seem to have downsides... either you have magic numbers in Kconfig or > you have configuration littered through include files. It feels like > it wants some piece of machinery we don't really have today. Long term, I think cases like this should be handled either way default 0xF00 if BAR or yes, we re-work things so it's out of the CONFIG namespace. In the case of bootcount_davinci.c we could easily key that off of CONFIG_AM33XX #elif CONFIG_SOC_DA8XX as we're talking about an on-chip RTC and that's not going to vary much in location. But for the generic driver that really is harder to say. -- 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/3] ARM: omap3: beagle, evm: synchronize common setup
On Sat, Feb 24, 2018 at 01:39:45PM -0600, Derald Woods wrote: > On Sat, Feb 24, 2018 at 02:12:32PM -0500, Tom Rini wrote: > > On Sat, Feb 24, 2018 at 09:29:02AM -0600, Derald D. Woods wrote: > > > On Sat, Feb 24, 2018 at 09:35:43AM -0500, Tom Rini wrote: > > > > On Sat, Feb 24, 2018 at 08:09:39AM -0600, Derald D. Woods wrote: > > > > > > > > > This short series is an attempt to make this set of boards use the > > > > > same > > > > > default configuration items where possible. This was prompted by an > > > > > investigation into enabling SERIAL_SEARCH_ALL on omap3_evm. This > > > > > feature > > > > > now works for omap3_evm after this series. > > > > > > > > > > The series changes the default NAND layout of MTDPARTS_DEFAULT and > > > > > uses ENV_IS_IN_FAT. More detail is provided with the patches. As most > > > > > things are configurable now, this should not be an issue. I am trying > > > > > to get simple defaults that just boot and expose the common core > > > > > features. This will make future testing and maintenance a bit more > > > > > predictable, as there will be a very similar comparable set of boards. > > > > > > > > I was thinking, wouldn't we want to update the beagle code now to do env > > > > in NAND on beagleboard and env on FAT on xM? We could provide a new > > > > env_get_location() to return the right location based on board. Thanks! > > > > > > > > > > I thought of that too. xM can never use NAND. So FAT is always right for > > > it. Regular BeagleBoard(3530) can have the environment in either location. > > > Configuration can simply handle the user preference. I did not see a > > > reason to add any more logic into an already heavy board file. The Overo > > > boards are equally heavy with board type logic. For now, my thinking > > > was to allow configuration do the work. > > > > OK, but on the other hand, xM must have an SD card inserted and vanilla > > does not require an SD card. So now those users need to put in an SD > > card. Now, I honestly don't know how big a deal that is really, so I > > won't nak the patches. But I do think it would be the best user > > experience to have classic continue to work as-is and xM to finally get > > functional env. > > > > I will try to add the 'env_get_location'. So let's hold until I can push a > 'v3' of the series. > > The possible env locations: > > ENVL_FAT > ENVL_MMC > ENVL_NAND > ENVL_UBI > > If those make sense, 'env_get_location' priority will select one of them. > Using 'env_get_location' is not working with this diff: ---8<-- diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index 1d55264733..22e6af7bb8 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "beagle.h" #include @@ -332,6 +333,34 @@ static struct musb_hdrc_platform_data musb_plat = { }; #endif +#if defined(CONFIG_SPL_BUILD) && \ + defined(CONFIG_ENV_IS_IN_NAND) && \ + defined(CONFIG_ENV_IS_IN_FAT) +enum env_location env_get_location(enum env_operation op, int prio) +{ + switch (prio) { + case 0: + return ENVL_FAT; + case 1: + switch (get_board_revision()) { + case REVISION_AXBX: + case REVISION_CX: + case REVISION_C4: + return ENVL_NAND; + case REVISION_XM_AB: + case REVISION_XM_C: + default: + return ENVL_FAT; + } + break; + default: + break; + } + + return ENVL_UNKNOWN; +} +#endif /* CONFIG_SPL_BUILD && CONFIG_ENV_IS_IN_{NAND,FAT} */ + /* * Routine: misc_init_r * Description: Configure board specific parts ---8<--- Additionally, it will not boot without using '#if defined(CONFIG_SPL_BUILD)'. When booting on BeagleBoard-xM, I get the following: ---8<--- U-Boot SPL 2018.03-rc3-00033-g881e2514dd-dirty (Feb 25 2018 - 12:26:00 -0600) Trying to boot from MMC1 spl_load_image_fat_os: error reading image args, err - -2 U-Boot 2018.03-rc3-00033-g881e2514dd-dirty (Feb 25 2018 - 12:26:00 -0600) OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz Model: TI OMAP3 BeagleBoard xM OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment Failed (-5) Loading Environment from NAND... *** Warning - readenv() failed, using default environment Failed (-5) Beagle xM Rev C No EEPROM on expansion board OMAP die ID: 46da00029ff80168300f15027017 Net: usb_ether starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Sto
Re: [U-Boot] [U-Boot, v2, 1/9] ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux
> Sync rk3288-vyasa board dts from Linux for proper updates and maintenance > - rk3288-vyasa.dts: Similar to Linux dts > - rk3288-vyasa-u-boot.dtsi: u-boot dts changes > > Also updated MAINTAINERS for these dts files. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/rk3288-vyasa-u-boot.dtsi | 29 +++ > arch/arm/dts/rk3288-vyasa.dts | 134 > ++--- > board/amarula/vyasa-rk3288/MAINTAINERS | 2 + > 3 files changed, 105 insertions(+), 60 deletions(-) > create mode 100644 arch/arm/dts/rk3288-vyasa-u-boot.dtsi > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/9] ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC
> rk808, SWITCH_REG1 has configured for sdmmc regulator as vcc_sd, > so use the same by renaming vcc33_sd to vcc_sd(as per schematic) > and drop explicit regulator definition from root. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/rk3288-vyasa.dts | 22 ++ > 1 file changed, 2 insertions(+), 20 deletions(-) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/9] ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1
> vdd_log, never used on DCDC_REG1 of rk808 from latest schematic so > remove the same and update the regulator-name as 'vdd_arm' to sync > with existing rk3288 board dts files. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/rk3288-vyasa.dts | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 5/9] ARM: dts: rockchip: Add gmac support for rk3288-vyasa board
> Sync gmac dts node from Linux. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Signed-off-by: Jagan Teki > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/rk3288-vyasa.dts | 41 + > 1 file changed, 41 insertions(+) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/9] ARM: dts: rockchip: Add regulators for rk3288-vyasa
> Add supporting regulators for rk3288-vyasa board, dc12_vbat is > parent regulatorand followed regulators as are child regulators. > regulator naming conversion followed as per schematic for better > readability and easy for identification. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/rk3288-vyasa.dts | 40 > 1 file changed, 40 insertions(+) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,9/9] rk3288: vyasa: Add eMMC boot support
> RK3288 Vyasa has eMMC boot support, with JP4 open. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > Note: > Linux patch for this support is in ML. > > arch/arm/dts/rk3288-vyasa-u-boot.dtsi | 4 > arch/arm/dts/rk3288-vyasa.dts | 11 +++ > board/amarula/vyasa-rk3288/vyasa-rk3288.c | 7 +++ > 3 files changed, 22 insertions(+) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 7/9] ARM: dts: rockchip: Add usb host for rk3288-vyasa
> Add usb host support for rk3288-vyasa, board support hub power > through phy_pwr_en and usb2 host power through usb2_pwr_en and > naming conversion followed as per schematic. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/rk3288-vyasa.dts | 48 > +++ > 1 file changed, 48 insertions(+) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 8/9] ARM: dts: rockchip: Add usb otg for rk3288-vyasa
> Add usb otg support for rk3288-vyasa, board support usb1 otg > power through otg_vbus_drv and naming conversion followed > as per schematic. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/rk3288-vyasa.dts | 25 + > 1 file changed, 25 insertions(+) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 6/9] rockchip: rk3288-vyasa: defconfig: Enable gmac support
> Enable gmac support for rk3288-vyasa board. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > configs/vyasa-rk3288_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > Applied to u-boot-rockchip/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 01/11] Merge CONFIG_BOOTCOUNT and CONFIG_BOOTCOUNT_LIMIT
On Fri, Feb 16, 2018 at 03:50:38PM +, Alex Kiernan wrote: > CONFIG_BOOTCOUNT was only used in mx53ppd, merge it with > CONFIG_BOOTCOUNT_LIMIT > > Signed-off-by: Alex Kiernan > Reviewed-by: Lukasz Majewski > Reviewed-by: Ian Ray 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] [U-Boot, v3, 02/11] Prepare for multiple bootcount drivers
On Fri, Feb 16, 2018 at 03:50:39PM +, Alex Kiernan wrote: > Reviewed-by: Lukasz Majewski > Signed-off-by: Alex Kiernan 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] [U-Boot, v3, 03/11] Convert CONFIG_BOOTCOUNT_AM33XX to Kconfig
On Fri, Feb 16, 2018 at 03:50:40PM +, Alex Kiernan wrote: > This converts the following to Kconfig: > CONFIG_BOOTCOUNT_AM33XX > > Reviewed-by: Lukasz Majewski > Reviewed-by: Hannes Schmelzer > Acked-by: Hannes Schmelzer > Signed-off-by: Alex Kiernan 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] [U-Boot, v3, 05/11] Convert CONFIG_BOOTCOUNT_RAM to Kconfig
On Fri, Feb 16, 2018 at 03:50:42PM +, Alex Kiernan wrote: > This converts the following to Kconfig: > CONFIG_BOOTCOUNT_RAM > > Signed-off-by: Alex Kiernan > Reviewed-by: Lukasz Majewski 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] [U-Boot, v3, 04/11] Convert CONFIG_BOOTCOUNT_ENV to Kconfig
On Fri, Feb 16, 2018 at 03:50:41PM +, Alex Kiernan wrote: > This converts the following to Kconfig: > CONFIG_BOOTCOUNT_ENV > > Signed-off-by: Alex Kiernan > Reviewed-by: Lukasz Majewski 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] [U-Boot,v3,08/11] Integrate AT91 bootcount driver
On Fri, Feb 16, 2018 at 03:50:45PM +, Alex Kiernan wrote: > Integrate Boot counter for Atmel AT91SAM9XE into Kconfig > > Reviewed-by: Lukasz Majewski > Signed-off-by: Alex Kiernan 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] [U-Boot, v3, 11/11] Remove CONFIG_SYS_BOOTCOUNT_SINGLEWORD
On Fri, Feb 16, 2018 at 03:50:48PM +, Alex Kiernan wrote: > Tidy up CONFIG_SYS_BOOTCOUNT_SINGLEWORD from the whitelist as there's > no remaining uses of it left. > > Signed-off-by: Alex Kiernan 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] [U-Boot, v3, 06/11] Convert CONFIG_BOOTCOUNT_I2C to Kconfig
On Fri, Feb 16, 2018 at 03:50:43PM +, Alex Kiernan wrote: > This converts the following to Kconfig: > CONFIG_BOOTCOUNT_I2C > > Signed-off-by: Alex Kiernan > Reviewed-by: Lukasz Majewski 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] [U-Boot, v3, 07/11] Convert CONFIG_BOOTCOUNT_EXT to Kconfig
On Fri, Feb 16, 2018 at 03:50:44PM +, Alex Kiernan wrote: > This converts the following to Kconfig: > CONFIG_BOOTCOUNT_EXT > > Signed-off-by: Alex Kiernan 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] [U-Boot, v3, 09/11] Migrate generic bootcount to Kconfig
On Fri, Feb 16, 2018 at 03:50:46PM +, Alex Kiernan wrote: > Make generate boot counter selected in the same way as other boot count > drivers > > Reviewed-by: Lukasz Majewski > Signed-off-by: Alex Kiernan 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] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR
On Sat, Feb 24, 2018 at 10:50:19PM -0500, Tom Rini wrote: > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig. We can > provide a default for BOOTCOUNT_AM33XX as that's a specific part of the > RTC in use. We can also provide a default for ARCH_LS1043A and > ARCH_LS1021A as they had been previously calculated and their symbols > are in Kconfig. In the case of other QE-enabled platforms, they are not > so we must update the relevant defconfig files. The previous default > only applied in some cases, even on a specific SoC family. > > Signed-off-by: Tom Rini With R-B's added, 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] [U-Boot, v3, 10/11] Migrate CONFIG_BOOTCOUNT_ALEN to Kconfig
On Fri, Feb 16, 2018 at 03:50:47PM +, Alex Kiernan wrote: > Convert CONFIG_BOOTCOUNT_ALEN to Kconfig > Signed-off-by: Alex Kiernan 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 v2 2/4] mmc: omap_hsmmc: compile out write support if not needed
On 02/23/2018 09:21 PM, Tom Rini wrote: > On Fri, Feb 23, 2018 at 10:40:17AM +0100, Jean-Jacques Hiblot wrote: > >> This reduces the size of the binary by about 196 bytes. >> >> Signed-off-by: Jean-Jacques Hiblot > > Reviewed-by: Tom Rini Applied to u-boot-mmc. Thanks! Best Regards, Jaehoon Chung > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] mmc: omap_hsmmc: make it possible to compile out ADMA support
On 02/23/2018 09:57 PM, Tom Rini wrote: > On Fri, Feb 23, 2018 at 01:47:36PM +0100, Jean-Jacques Hiblot wrote: >> >> >> On 23/02/2018 13:21, Tom Rini wrote: >>> On Fri, Feb 23, 2018 at 10:40:18AM +0100, Jean-Jacques Hiblot wrote: Some platforms don't have ADMA controllers. For those platforms, compiling it out reduces the size of the binary by about 600 bytes. Leaving the support in doesn't break things as the driver checks at runtime if the ADMA2 controller is present. Signed-off-by: Jean-Jacques Hiblot --- Changes in v2: - Use a Kconfig option to compile out the ADMA support instead of relying on the platform architecture drivers/mmc/Kconfig | 9 + drivers/mmc/omap_hsmmc.c | 12 ++-- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index f2d8256..88a1359 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -239,6 +239,15 @@ config MMC_OMAP_HS If unsure, say N. +config MMC_OMAP_HS_ADMA + bool "ADMA support for OMAP HS MMC" + depends on MMC_OMAP_HS && !OMAP34XX + default y if !AM33XX >>> Is this logic really the right restrictions? Does it work on some >>> AM33XX platforms (AM43xx?) and just never OMAP34XX? Thanks! >> Starting with platform am33xx there is a way to check if the ADMA controller >> is present or not by reading a register. This register is not available in >> OMAP34XX. >> That being said I don't think that ADMA is available on any variant of >> am33xx. > > OK, thanks! > > Reviewed-by: Tom Rini Applied to u-boot-mmc. Thanks! Best Regards, Jaehoon Chung > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified
On 02/23/2018 09:21 PM, Tom Rini wrote: > On Fri, Feb 23, 2018 at 10:40:19AM +0100, Jean-Jacques Hiblot wrote: > >> mmc_of_parse() doesn't set a default value if none is available in DT. >> In that case, use a default 52MHz clock rate. >> >> Signed-off-by: Alex Kiernan >> Signed-off-by: Jean-Jacques Hiblot >> > > Reviewed-by: Tom Rini Applied to u-boot-mmc. Thanks! Best Regards, Jaehoon Chung > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat
On 02/23/2018 09:21 PM, Tom Rini wrote: > On Fri, Feb 23, 2018 at 10:40:16AM +0100, Jean-Jacques Hiblot wrote: > >> The area for struct mmc can be allocated dynamically. It greatly reduces >> the size of struct omap_hsmmc_plat. This is useful in cases where the board >> level code declares one or two struct omap_hsmmc_plat because it doesn't >> use the Driver Model. >> >> This saves around 740 bytes for the am335x_evm SPL. >> >> Signed-off-by: Jean-Jacques Hiblot > > Reviewed-by: Tom Rini Applied to u-boot-mmc. Thanks! Best Regards, Jaehoon Chung > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT PULL ] Please pull u-boot-mmc master
Dear Tom, Could you pull these patches to u-boot/master? The following changes since commit f0f6917188ad660cf002c10095f46ecf748b8f58: Prepare v2018.03-rc3 (2018-02-20 16:51:56 -0500) are available in the Git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to beac7d33d9131d22ffbdbfbf2786858062b63786: mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified (2018-02-26 10:52:15 +0900) Alexander Kochetkov (1): mmc: fix off-by-one bug in mmc_startup_v4() Faiz Abbas (1): mmc: Drop unnecessary case for mmc_probe() Jaehoon Chung (1): mmc: synchronize the sequence with enum bus_mode in mmc.h Jean-Jacques Hiblot (4): mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat mmc: omap_hsmmc: compile out write support if not needed mmc: omap_hsmmc: make it possible to compile out ADMA support mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified arch/arm/include/asm/omap_mmc.h | 2 +- drivers/mmc/Kconfig | 9 + drivers/mmc/mmc.c | 20 +--- drivers/mmc/omap_hsmmc.c| 31 --- 4 files changed, 35 insertions(+), 27 deletions(-) Best Regards, Jaehoon Chung ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] core: do not fail in device_probe() when clk set default fail
On 02/25/2018 06:52 PM, Dr. Philipp Tomsich wrote: >> On 25 Feb 2018, at 11:24, Kever Yang wrote: >> >> Assigned clocks are widely used in kernel, but not in U-Boot yet, >> many U-Boot clock driver do not have the API while dts port from kernel >> have "assigned-clocks" node. >> >> Just give a warning now instead of a device probe fail. > I strongly disagree on this one: the only reason this can fail is if > assigned-clock-rates > can not be set (e.g. because a clock that should be assigned to is not known > by the > clock driver). However, this should never be ignored silently. Whe we search "assigned-clocks" in dts, you can see a lot of result in different platform, just as I mentioned in commit message because this is widely used in kernel. In other hand, when we search "set_parent" in clock driver, only part of Rockchip SoCs support it, and only GMAC support this, everything else will get an error return and failed in device_probe() which means driver been broken. I think it's more reasonable to like pinctrl, we can try to set it, but not fail on error return, or else too many modules been break before they are ready to support the new feature. Or maybe we should not return error if ops->set_parent is empty. > > If the clock subsystem does not know all clocks that are being attempted to > set, then > commits to shared drivers will eventually break: e.g. commit ba1f96672522 > ("net: designware: add clock support”) recently broke the GMAC for the RK3368 > and > RK3399 because it iterated over all clocks defined in the “clocks” property > of the > GMAC node. > > As long as various drivers perform an unconditional clk_enable and/or an > unconditional > clk_set_rate, we should enforce this in the core already. In consequence, > dedicated > code from the drivers should now start to slowly disappear, as clock-rates > can now be > set via the DTS. This is an option in kernel for a long time, but not mandatory, so we should make both(the new feature and drivers already there) work, or clean and replace everything in driver already there before enforce to use the new feature in core. Thanks, - Kever > >> Signed-off-by: Kever Yang >> --- >> >> drivers/core/device.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/core/device.c b/drivers/core/device.c >> index 9d58f44..71872e9 100644 >> --- a/drivers/core/device.c >> +++ b/drivers/core/device.c >> @@ -407,7 +407,7 @@ int device_probe(struct udevice *dev) >> /* Process 'assigned-{clocks/clock-parents/clock-rates}' properties */ >> ret = clk_set_defaults(dev); >> if (ret) >> -goto fail; >> +debug("%s clk_set_defaults failed %d\n", ret); > This probably shouldn’t have been a silent failure. > A pr_err() may be more appropriate… I would recommend this to continue failing > though, as it is simple enough to handle the additional clocks in the clock > drivers > and create a permanent record of “things not needing additional changes, due > to > the BROM already having set up things” by returning success. > >> if (drv->probe) { >> ret = drv->probe(dev); >> -- >> 1.9.1 >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] core: add uclass_get_device_by_phandle_id() api
Hi Simon, On 02/25/2018 11:54 PM, Simon Glass wrote: > Hi Kever, > > On 23 February 2018 at 19:08, Kever Yang wrote: >> Hi Simon, >> >> >> On 02/12/2018 10:35 PM, Simon Glass wrote: >>> Hi Kever, >>> >>> On 8 February 2018 at 19:56, Kever Yang wrote: Add api for who can not get phandle from a device property. >>> Can you please add a motivation to the commit message? It is not >>> obvious to me when this function would be used. >> Here is the example why I need this, see the dts node here: >> lvds@ff2e { >> ... >> rockchip,grf = <&grf>; >> port { >> port@0 { >> endpoint@0 { >> remote-endpoint = <&vopl_out_lvds>; >> } >> } >> } >> } >> >> We can only get 'grf' udevice by uclass_get_device_by_phandle(), >> but we not able to get udevice 'vopl_out_lvds', other driver like >> rockchip pinctrl >> also need to get udevice by a phandle which is not one of direct property of >> another device node. > OK I see. This sort of info is useful in the commit message. It helps > to know two things about a patch: > > - why it is needed > - what it does > > In this case see rk_display_init() for how it handles the > 'remote-endpoint' property. I think it would be better to have > something like: > > ofnode ofnode_lookup_phandle(ofnode node, const char *prop_name); Yes, this is enough for "remote-endpoint" case, but not for pinctrl case: 1199 pinctrl: pinctrl { 2095 pwm0 { 2096 pwm0_pin: pwm0-pin { 2097 rockchip,pins = 2098 <0 RK_PB7 RK_FUNC_1 &pcfg_pull_none>; 2099 }; 2100 }; I think ofnode_lookup_phandle() still not able to find node for 'pcfg_pull_none'. Thanks, - Kever > > This should meet your needs without needing to decoding the phandle > property in the caller. > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] Please pull u-boot-imx
On Sat, Feb 24, 2018 at 04:58:14PM +0100, Stefano Babic wrote: > Hi Tom, > > some fixes, please pull from u-boot-imx, thanks! > > The following changes since commit 02b0895c215e252cff50d9edf53a972d2bbbfd30: > > Merge git://git.denx.de/u-boot-sh (2018-02-17 16:06:59 -0500) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to 3d409153502f25a1ea3b8b4e9940148b7871273d: > > imx6q: engicam: Use SPL_LOAD_FIT for MMC boards (2018-02-22 14:51:01 > +0100) > For the updated version, 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] Please pull u-boot-rockchip/master
On Sun, Feb 25, 2018 at 11:43:13AM +0100, Dr. Philipp Tomsich wrote: > Tom, > > we have additional fixes ready for you: > * the TPL-build process for the Vyasa board was fixed by Jagan (by > providing the correct TEXT_BASE) > * a regression on Ethernet for the RK3399 and RK3368 has been resolved > by adding support for its clocks > * a regression on PMIC probing on the RK399 has been resolved by adding > support for the assigned-clocks of the PMUCRU > > Travis report is at > https://travis-ci.org/ptomsich/u-boot-rockchip/builds/345699336 > > Thanks, > Philipp. > > > The following changes since commit 0bb430c8494e26e8d258cf6957cdd39d2ce4f309: > > Merge git://git.denx.de/u-boot-video (2018-02-24 08:02:17 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip.git master > > for you to fetch changes up to 434d5a00a4578f826e7e2cef29bf2388dd760a88: > > rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL (2018-02-24 > 18:50:03 +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] Please pull u-boot-rockchip/master
On Sun, Feb 25, 2018 at 11:43:13AM +0100, Dr. Philipp Tomsich wrote: > Tom, > > we have additional fixes ready for you: > * the TPL-build process for the Vyasa board was fixed by Jagan (by > providing the correct TEXT_BASE) > * a regression on Ethernet for the RK3399 and RK3368 has been resolved > by adding support for its clocks RK3288 and others share the same regression. 'designware: fix clock enable' fixed it but is not in master yet. https://patchwork.ozlabs.org/patch/869785/ > * a regression on PMIC probing on the RK399 has been resolved by adding > support for the assigned-clocks of the PMUCRU > > Travis report is at > https://travis-ci.org/ptomsich/u-boot-rockchip/builds/345699336 > > Thanks, > Philipp. > > > The following changes since commit 0bb430c8494e26e8d258cf6957cdd39d2ce4f309: > > Merge git://git.denx.de/u-boot-video (2018-02-24 08:02:17 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip.git master > > for you to fetch changes up to 434d5a00a4578f826e7e2cef29bf2388dd760a88: > > rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL (2018-02-24 > 18:50:03 +0100) > > > Jagan Teki (2): > rockchip: rk3288: Add TPL_LDSCRIPT > rockchip: rk3288: Fix wrong TPL_TEXT_BASE > > Philipp Tomsich (3): > rockchip: clk: rk3399: handle clk_enable requests for GMAC > rockchip: clk: rk3368: handle clk_enable requests for GMAC > rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL > > arch/arm/mach-rockchip/Kconfig | 10 ++ > arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++ > configs/vyasa-rk3288_defconfig | 1 - > drivers/clk/rockchip/clk_rk3368.c| 19 +++ > drivers/clk/rockchip/clk_rk3399.c| 19 +++ > 5 files changed, 58 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > > ___ > 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 v8 4/4] common: Generic firmware loader for file system
On Thu, 2018-02-22 at 15:28 +0100, Marek Vasut wrote: > On 02/22/2018 09:18 AM, Chee, Tien Fong wrote: > > > > On Thu, 2018-02-15 at 15:58 +0100, Marek Vasut wrote: > > > > > > On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > This is file system generic loader which can be used to load > > > > the file image from the storage into target such as memory. > > > > The consumer driver would then use this loader to program > > > > whatever, > > > > ie. the FPGA device. > > > > > > > > Signed-off-by: Tien Fong Chee > > > > Reviewed-by: Lothar Waßmann > > > [...] > > > > > > > > > > > > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#ifdef CONFIG_SPL > > > Are the ifdefs needed ? > > > > > Because spl.h contains some codes have its dependency with SPL. So, > > Tom > > adviced to make this part of code depend on CONFIG_SPL. > > However, only __weak int init_mmc() depend on the codes from spl.h, > > so > > user can override their own init_mmc() if SPL is not used. > You probably dont need those ifdefs around headers. > > > > > > > > > > > > > > +#include > > > > +#endif > > > > +#include > > > > +#ifdef CONFIG_CMD_UBIFS > > > > +#include > > > > +#include > > > > +#endif > > > > +#include > > > > + > > > > +struct firmware_priv { > > > > + const char *name; /* Filename */ > > > > + u32 offset; /* Offset of reading a file > > > > */ > > > > +}; > > > > + > > > > +static struct device_location default_locations[] = { > > > > + { > > > > + .name = "mmc", > > > > + .devpart = "0:1", > > > > + }, > > > > + { > > > > + .name = "usb", > > > > + .devpart = "0:1", > > > > + }, > > > > + { > > > > + .name = "sata", > > > > + .devpart = "0:1", > > > > + }, > > > How can this load from UBI if it's not listed here ? > Well ? > I can add ".name = ubi" and ".devpart = UBI" . > [...] > > > > > > > > > > > > > > +#ifdef CONFIG_SATA > > > > +static int init_storage_sata(void) > > > > +{ > > > > + return sata_probe(0); > > > Shouldn't the sata device number be pulled from devpart in > > > default_locations table ? > > > > > This may need to add the logic for splitting the device number and > > partition into integer from the string. Let me think how to do it, > > may > > be i can leverage existing code. > strtok(), strtol() or something ? > yes, plan to use that. > [...] > > > > > > > > > > > > > > +#ifdef CONFIG_SPL > > > > + spl_mmc_find_device(&mmc, spl_boot_device()); > > > > +#else > > > > + debug("#define CONFIG_SPL is required or overrriding > > > > %s\n", > > > > + __func__); > > > This can be a compile-time error, maybe ? > > > > > No compile error. When you open the file, "%s\n" is actually same > > line > > with debug(". . > So what ? This missing macro can be detected at runtime, heck this > code > can even depend on CONFIG_SPL in Kconfig. > Oh...I got you, i thought you means syntax error. So, i would remove it and adding the depend on CONFIG_SPL in Kconfig. > > > > > > > > > > > > > > > > > + return -ENOENT; > > > > +#endif > > > > + > > > > + err = mmc_init(mmc); > > > > + if (err) { > > > > + debug("spl: mmc init failed with error: %d\n", > > > > err); > > > > + return err; > > > > + } > > > > + > > > > + return err; > > > > +} > > > > +#else > > > > +__weak int init_mmc(void) > > > > +{ > > > > + /* Expect somewhere already initialize MMC */ > > > > + return 0; > > > > +} > > > > +#endif > > > [...] > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system
On Thu, 2018-02-22 at 10:50 -0500, Tom Rini wrote: > On Thu, Feb 22, 2018 at 03:28:12PM +0100, Marek Vasut wrote: > > > > On 02/22/2018 09:18 AM, Chee, Tien Fong wrote: > > > > > > On Thu, 2018-02-15 at 15:58 +0100, Marek Vasut wrote: > > > > > > > > On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > > > This is file system generic loader which can be used to load > > > > > the file image from the storage into target such as memory. > > > > > The consumer driver would then use this loader to program > > > > > whatever, > > > > > ie. the FPGA device. > > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > Reviewed-by: Lothar Waßmann > > > > [...] > > > > > > > > > > > > > > > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#ifdef CONFIG_SPL > > > > Are the ifdefs needed ? > > > > > > > Because spl.h contains some codes have its dependency with SPL. > > > So, Tom > > > adviced to make this part of code depend on CONFIG_SPL. > > > However, only __weak int init_mmc() depend on the codes from > > > spl.h, so > > > user can override their own init_mmc() if SPL is not used. > > You probably dont need those ifdefs around headers. > In this case, we do. You can only include on architectures > which have SPL support. > > I wouldn't object to a separate patch series that adds a dummy > asm-generic/spl.h and we go that route, if it also cleans up more of > the > code in general. But I think that's separate from this > series. Thanks! > Planning to add the depend on CONFIG_SPL in Kconfig instead of ifdefs . ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system
On Thu, 2018-02-22 at 10:02 +0100, Lothar Waßmann wrote: > Hi, > > On Mon, 5 Feb 2018 15:06:49 +0800 tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > This is file system generic loader which can be used to load > > the file image from the storage into target such as memory. > > The consumer driver would then use this loader to program whatever, > > ie. the FPGA device. > > > > Signed-off-by: Tien Fong Chee > > Reviewed-by: Lothar Waßmann > > --- > > common/Kconfig | 9 ++ > > common/Makefile| 1 + > > common/fs_loader.c | 320 > > + > > doc/README.firmware_loader | 76 +++ > > include/fs_loader.h| 28 > > 5 files changed, 434 insertions(+) > > create mode 100644 common/fs_loader.c > > create mode 100644 doc/README.firmware_loader > > create mode 100644 include/fs_loader.h > > > [...] > > > > +#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD) > > +__weak int init_mmc(void) > > +{ > > + /* Just for the case MMC is not yet initialized */ > > + struct mmc *mmc = NULL; > > + int err; > > + > > +#ifdef CONFIG_SPL > > + spl_mmc_find_device(&mmc, spl_boot_device()); > > +#else > > + debug("#define CONFIG_SPL is required or overrriding > > %s\n", > > > s/overrr/overr/ > I would remove it and adding the depend on CONFIG_SPL in Kconfig for compile-time error checking. > > > Lothar Waßmann ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rockchip: rk3288: Add TPL_LDSCRIPT
I prefer to share the TPL script between all Rockchip SoCs, and put this at arch/arm/mach-rockchip/. I got one in my local branch, will update it once I clean up everything. Thanks, - Kever On 02/23/2018 03:43 PM, Jagan Teki wrote: > Due to size limitations in SPL by adding falcon mode, > rk3288 support TPL. In order to not overlap SPL_TEXT_BASE > add TPL_TEXT_BASE with u-boot-tpl.lds that intern call > u-boot-spl.lds with proper TEXT_BASE values. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > --- > Changes for v2: > - none > > arch/arm/mach-rockchip/Kconfig | 7 +++ > arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++ > 2 files changed, 17 insertions(+) > create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index 1e5a7bb79b..d9218da64f 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -72,6 +72,13 @@ config ROCKCHIP_RK3288 > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs. > > +if ROCKCHIP_RK3288 > + > +config TPL_LDSCRIPT > + default "arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds" > + > +endif > + > config ROCKCHIP_RK3328 > bool "Support Rockchip RK3328" > select ARM64 > diff --git a/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > new file mode 100644 > index 00..c7a60929e6 > --- /dev/null > +++ b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > @@ -0,0 +1,10 @@ > +/* > + * Copyright (C) 2018 Jagan Teki > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#undef CONFIG_SPL_TEXT_BASE > +#define CONFIG_SPL_TEXT_BASE CONFIG_TPL_TEXT_BASE > + > +#include "../../cpu/u-boot-spl.lds" ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rockchip: rk3288: Add TPL_LDSCRIPT
I prefer to share the TPL script between all Rockchip SoCs, and put this at arch/arm/mach-rockchip/. I got one in my local branch, will update it once I clean up everything. Thanks, - Kever On 02/23/2018 03:43 PM, Jagan Teki wrote: > Due to size limitations in SPL by adding falcon mode, > rk3288 support TPL. In order to not overlap SPL_TEXT_BASE > add TPL_TEXT_BASE with u-boot-tpl.lds that intern call > u-boot-spl.lds with proper TEXT_BASE values. > > Signed-off-by: Jagan Teki > Acked-by: Philipp Tomsich > --- > Changes for v2: > - none > > arch/arm/mach-rockchip/Kconfig | 7 +++ > arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++ > 2 files changed, 17 insertions(+) > create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index 1e5a7bb79b..d9218da64f 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -72,6 +72,13 @@ config ROCKCHIP_RK3288 > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs. > > +if ROCKCHIP_RK3288 > + > +config TPL_LDSCRIPT > + default "arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds" > + > +endif > + > config ROCKCHIP_RK3328 > bool "Support Rockchip RK3328" > select ARM64 > diff --git a/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > new file mode 100644 > index 00..c7a60929e6 > --- /dev/null > +++ b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds > @@ -0,0 +1,10 @@ > +/* > + * Copyright (C) 2018 Jagan Teki > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#undef CONFIG_SPL_TEXT_BASE > +#define CONFIG_SPL_TEXT_BASE CONFIG_TPL_TEXT_BASE > + > +#include "../../cpu/u-boot-spl.lds" ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot