Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On 27/11/2019 17.05, Marek Vasut wrote: > On 11/27/19 4:40 PM, Claudius Heine wrote: >> On 27/11/2019 16.21, Marek Vasut wrote: >>> On 11/27/19 4:17 PM, Claudius Heine wrote: On 27/11/2019 16.12, Marek Vasut wrote: > On 11/27/19 4:09 PM, Claudius Heine wrote: >> Hi Marek, >> >> On 27/11/2019 15.47, Marek Vasut wrote: >>> On 11/27/19 3:20 PM, Claudius Heine wrote: In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available anywere, even if SYSRESET is disabled for SPL in the board specific header file like this: #if defined(CONFIG_SPL_BUILD) #undef CONFIG_WDT #undef CONFIG_WATCHDOG #undef CONFIG_SYSRESET #define CONFIG_HW_WATCHDOG #endif 'do_reset' is called from SPL for instance from the panic handler in case SPL_USB_SDP is enabled and PANIC_HANG is not set. Setting PANIC_HANG would solve this issue, but it also changes the behavior in case a panic occurs. Signed-off-by: Claudius Heine --- arch/arm/lib/Makefile | 2 -- arch/arm/lib/reset.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 9de9a9acee..763eb4498f 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -56,9 +56,7 @@ obj-y+= interrupts_64.o else obj-y += interrupts.o endif -ifndef CONFIG_SYSRESET obj-y += reset.o -endif obj-y += cache.o obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c index f3ea116e87..11e680be1d 100644 --- a/arch/arm/lib/reset.c +++ b/arch/arm/lib/reset.c @@ -22,6 +22,7 @@ #include +#if !defined(CONFIG_SYSRESET) __weak void reset_misc(void) { } @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /*NOTREACHED*/ return 0; } +#endif >>> >>> Does this mean there's now one huge ifdef around the entire source file? >>> That's odd. >> >> Right. Other suggestions? >> >> Maybe having 'do_reset' here as a weak instead, so that sysreset can >> overwrite it? But then the other definitions in arch/*/lib/reset.c >> should probably be the same for consistency sake? >> >> I tried with this patch not to change anything in case SYSRESET is >> enabled too much and since the file isn't too large I thought that would >> be ok for now. > > What if sysreset implemented do_reset ? Wouldn't that solve the issue ? Not sure what you mean... sysreset implements do_reset: https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/sysreset/sysreset-uclass.c#L112 But the SPL does not have sysreset in this case, so it needs something different. >>> >>> Oh, so you need CONFIG_$(SPL_TPL_)SYSRESET then ? >> >> Well that would probably not enough. I would also need settings for the >> watchdog, because the SPL does not have DM support, so while u-boot uses >> CONFIG_WATCHDOG the SPL uses CONFIG_HW_WATCHDOG. >> >> Easier that changing all this is something like this in the board header >> file (as I described in the commit description): >> >> #if defined(CONFIG_SPL_BUILD) >> #undef CONFIG_WDT >> #undef CONFIG_WATCHDOG >> #undef CONFIG_SYSRESET >> #define CONFIG_HW_WATCHDOG >> #endif > > Can't we add DM watchdog to SPL instead ? Do you mean implementing SPL_DM support for this board so that we can use the DM watchdog and sysreset? Well you know more about this than me. But it probably comes down to technical limitations like size of the SPL. Lukasz has done something similar with the display5 board [1], but that uses PANIC_HANG to avoid this issue. [1] https://gitlab.denx.de/u-boot/u-boot/blob/4b19b89ca4a866b7baa642533e6dbd67cd832d27/include/configs/display5.h#L343 > >> In case of imx6, that way the SPL uses the hw_watchdog_reset from the >> imx watchdog driver instead of the 'watchdog_reset'. >> >> 'watchdog_reset' is not available since that is implemented in >> wdt-uclass.c and CONFIG_SPL_WDT depends on SPL_DM ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] rockchip: px30: enable spl-fifo-mode for both emmc and sdmmc on evb
Hi Patrick, Am Donnerstag, 28. November 2019, 00:38:45 CET schrieb Patrick Wildt: > On Tue, Nov 19, 2019 at 12:04:02PM +0100, Heiko Stuebner wrote: > > From: Heiko Stuebner > > > > As part of loading trustedfirmware, the SPL is required to place portions > > of code into the socs sram but the mmc controllers can only do dma > > transfers into the regular memory, not sram. > > > > The results of this are not directly visible in u-boot itself, but > > manifest as security-relate cpu aborts during boot of for example Linux. > > > > There were a number of attempts to solve this elegantly but so far > > discussion is still ongoing, so to make the board at least boot correctly > > put both mmc controllers into fifo-mode, which also circumvents the > > issue for now. > > > > Signed-off-by: Heiko Stuebner > > Hi, > > is this also needed on RK3399 based machines? I have a NanoPC-T4, > where the eMMC is on the Arasan controller and the SD card on the > dwmmc. So if I boot from SD card I need this as well? I think so. That dma-to-sram issue is supposed to be present on a lot (maybe all?) Rockchip SoCs. And I think I remember running into that issue on rk3399 as well already in the past. Not sure if that is limited to the dw-mmc only though or the arasan is also affected - maybe Kever knows :-) Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On Wed, Nov 27, 2019 at 4:40 PM Claudius Heine wrote: > > On 27/11/2019 16.21, Marek Vasut wrote: > > On 11/27/19 4:17 PM, Claudius Heine wrote: > >> On 27/11/2019 16.12, Marek Vasut wrote: > >>> On 11/27/19 4:09 PM, Claudius Heine wrote: > Hi Marek, > > On 27/11/2019 15.47, Marek Vasut wrote: > > On 11/27/19 3:20 PM, Claudius Heine wrote: > >> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be > >> available > >> anywere, even if SYSRESET is disabled for SPL in the board specific > >> header > >> file like this: > >> > >> #if defined(CONFIG_SPL_BUILD) > >> #undef CONFIG_WDT > >> #undef CONFIG_WATCHDOG > >> #undef CONFIG_SYSRESET > >> #define CONFIG_HW_WATCHDOG > >> #endif > >> > >> 'do_reset' is called from SPL for instance from the panic handler in > >> case > >> SPL_USB_SDP is enabled and PANIC_HANG is not set. > >> > >> Setting PANIC_HANG would solve this issue, but it also changes the > >> behavior > >> in case a panic occurs. > >> > >> Signed-off-by: Claudius Heine > >> --- > >> arch/arm/lib/Makefile | 2 -- > >> arch/arm/lib/reset.c | 2 ++ > >> 2 files changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > >> index 9de9a9acee..763eb4498f 100644 > >> --- a/arch/arm/lib/Makefile > >> +++ b/arch/arm/lib/Makefile > >> @@ -56,9 +56,7 @@ obj-y += interrupts_64.o > >> else > >> obj-y += interrupts.o > >> endif > >> -ifndef CONFIG_SYSRESET > >> obj-y += reset.o > >> -endif > >> > >> obj-y += cache.o > >> obj-$(CONFIG_SYS_ARM_CACHE_CP15)+= cache-cp15.o > >> diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c > >> index f3ea116e87..11e680be1d 100644 > >> --- a/arch/arm/lib/reset.c > >> +++ b/arch/arm/lib/reset.c > >> @@ -22,6 +22,7 @@ > >> > >> #include > >> > >> +#if !defined(CONFIG_SYSRESET) > >> __weak void reset_misc(void) > >> { > >> } > >> @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, > >> char * const argv[]) > >> /*NOTREACHED*/ > >> return 0; > >> } > >> +#endif > > > > Does this mean there's now one huge ifdef around the entire source file? > > That's odd. > > Right. Other suggestions? > > Maybe having 'do_reset' here as a weak instead, so that sysreset can > overwrite it? But then the other definitions in arch/*/lib/reset.c > should probably be the same for consistency sake? > > I tried with this patch not to change anything in case SYSRESET is > enabled too much and since the file isn't too large I thought that would > be ok for now. > >>> > >>> What if sysreset implemented do_reset ? Wouldn't that solve the issue ? > >> > >> Not sure what you mean... sysreset implements do_reset: > >> > >> https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/sysreset/sysreset-uclass.c#L112 > >> > >> But the SPL does not have sysreset in this case, so it needs something > >> different. > > > > Oh, so you need CONFIG_$(SPL_TPL_)SYSRESET then ? > > Well that would probably not enough. I would also need settings for the > watchdog, because the SPL does not have DM support, so while u-boot uses > CONFIG_WATCHDOG the SPL uses CONFIG_HW_WATCHDOG. > > Easier that changing all this is something like this in the board header > file (as I described in the commit description): > > #if defined(CONFIG_SPL_BUILD) > #undef CONFIG_WDT > #undef CONFIG_WATCHDOG > #undef CONFIG_SYSRESET > #define CONFIG_HW_WATCHDOG > #endif > > In case of imx6, that way the SPL uses the hw_watchdog_reset from the > imx watchdog driver instead of the 'watchdog_reset'. > > 'watchdog_reset' is not available since that is implemented in > wdt-uclass.c and CONFIG_SPL_WDT depends on SPL_DM. That seems totally unrelated to this patch. I think this patch should change the Makefile to use CONFIG_$(SPL_TPL_)SYSRESET and you need to solve your watchdog issue in a separate patch. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: reset: use do_reset in SPL/TPL if SYSRESET was not enabled for them
In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available anywere, even if SYSRESET is disabled for SPL/TPL. 'do_reset' is called from SPL for instance from the panic handler and PANIC_HANG is not set Signed-off-by: Claudius Heine --- arch/arm/lib/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 9de9a9acee..7bf2c077ba 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -56,7 +56,7 @@ obj-y += interrupts_64.o else obj-y += interrupts.o endif -ifndef CONFIG_SYSRESET +ifndef CONFIG_$(SPL_TPL_)SYSRESET obj-y += reset.o endif -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Using sspi for hardware detection?
Hi, Le 27/11/2019 à 21:13, Simon Goldschmidt a écrit : > On Wed, Nov 27, 2019 at 1:58 PM Romain Naour wrote: >> >> Hello, >> >> I'm working on a modular socfpga based system with several optional boards. >> Each optional board contain a board ID that can be read through a SPI bus. >> >> Since we want just read the board ID, we used manually the sspi command, >> something like: >> >> => sspi 1:1.0 8 0 >> 42 >> >> But it seems that the sspi command can't be used in a uboot script. sspi >> seems >> only used to manually test spi drivers. >> >> >> If we compare with i2c command, we have a i2c read to memory: >> >> i2c read chip address[.0, .1, .2] length memaddress - read to memory >> >> Why there is no such feature for spi ? > > Probably because noone has needed it so far. > >> Is there an interest to evolve the sspi command to add a read to memory? >> >> sspi : . > > If you need it and provide a decent patch, I could probable get accepted... Ok I'll take a look how to implement this. > >> >> By looking at existing code, it seems that hardware detection in uboot is >> handled by architecture/board specific code to set custom environment >> variable >> like "fpgatype" [1] or "unit_ident" "unit_serial" [2] (misc_init_r). >> >> What do you recommend? >> Implement a custom misc_init_r() for hardware detection? > > How is that related? How does reading to memory help you with knowing the hw > type in scripts? Sorry, actually this is another possibility. The first possibility is evolve the sspi command to add . This allow to use a script working on memory containing the data received from the spi bus. For my use case, it would allow to get the board ID in memory and use an uboot script analyze which board ID has been read. The second possibility is to use misc_init_r (or as you suggest board_late_init) in a board specific code (board///socfpga.c) to access the spi bus and set custom environment variable. These environment variable are later used by uboot script. I would like an advice on the best implementation. I believe modifying sspi command can be the way to go since it can be used for other use case. > > Anyway, I think board_late_init is a better fit than misc_init_r, > which is rather > meant to be a platform thing and vining can only use it because socfpga > doesn't need it otherwise. Thanks for your feed back! Best regards, Romain > > Regards, > Simon > >> >> [1] >> https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/misc_gen5.c#L139 >> [2] >> https://gitlab.denx.de/u-boot/u-boot/blob/master/board/softing/vining_fpga/socfpga.c#L48 >> >> Best regards, >> Romain >> ___ >> 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] ARM: reset: Move SYSRESET condition from Makefile into source file
On 11/28/19 9:10 AM, Claudius Heine wrote: > On 27/11/2019 17.05, Marek Vasut wrote: >> On 11/27/19 4:40 PM, Claudius Heine wrote: >>> On 27/11/2019 16.21, Marek Vasut wrote: On 11/27/19 4:17 PM, Claudius Heine wrote: > On 27/11/2019 16.12, Marek Vasut wrote: >> On 11/27/19 4:09 PM, Claudius Heine wrote: >>> Hi Marek, >>> >>> On 27/11/2019 15.47, Marek Vasut wrote: On 11/27/19 3:20 PM, Claudius Heine wrote: > In case CONFIG_SYSRESET is set, do_reset from reset.c will not be > available > anywere, even if SYSRESET is disabled for SPL in the board specific > header > file like this: > > #if defined(CONFIG_SPL_BUILD) > #undef CONFIG_WDT > #undef CONFIG_WATCHDOG > #undef CONFIG_SYSRESET > #define CONFIG_HW_WATCHDOG > #endif > > 'do_reset' is called from SPL for instance from the panic handler in > case > SPL_USB_SDP is enabled and PANIC_HANG is not set. > > Setting PANIC_HANG would solve this issue, but it also changes the > behavior > in case a panic occurs. > > Signed-off-by: Claudius Heine > --- > arch/arm/lib/Makefile | 2 -- > arch/arm/lib/reset.c | 2 ++ > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > index 9de9a9acee..763eb4498f 100644 > --- a/arch/arm/lib/Makefile > +++ b/arch/arm/lib/Makefile > @@ -56,9 +56,7 @@ obj-y += interrupts_64.o > else > obj-y+= interrupts.o > endif > -ifndef CONFIG_SYSRESET > obj-y+= reset.o > -endif > > obj-y+= cache.o > obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o > diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c > index f3ea116e87..11e680be1d 100644 > --- a/arch/arm/lib/reset.c > +++ b/arch/arm/lib/reset.c > @@ -22,6 +22,7 @@ > > #include > > +#if !defined(CONFIG_SYSRESET) > __weak void reset_misc(void) > { > } > @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, > char * const argv[]) > /*NOTREACHED*/ > return 0; > } > +#endif Does this mean there's now one huge ifdef around the entire source file? That's odd. >>> >>> Right. Other suggestions? >>> >>> Maybe having 'do_reset' here as a weak instead, so that sysreset can >>> overwrite it? But then the other definitions in arch/*/lib/reset.c >>> should probably be the same for consistency sake? >>> >>> I tried with this patch not to change anything in case SYSRESET is >>> enabled too much and since the file isn't too large I thought that would >>> be ok for now. >> >> What if sysreset implemented do_reset ? Wouldn't that solve the issue ? > > Not sure what you mean... sysreset implements do_reset: > > https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/sysreset/sysreset-uclass.c#L112 > > But the SPL does not have sysreset in this case, so it needs something > different. Oh, so you need CONFIG_$(SPL_TPL_)SYSRESET then ? >>> >>> Well that would probably not enough. I would also need settings for the >>> watchdog, because the SPL does not have DM support, so while u-boot uses >>> CONFIG_WATCHDOG the SPL uses CONFIG_HW_WATCHDOG. >>> >>> Easier that changing all this is something like this in the board header >>> file (as I described in the commit description): >>> >>> #if defined(CONFIG_SPL_BUILD) >>> #undef CONFIG_WDT >>> #undef CONFIG_WATCHDOG >>> #undef CONFIG_SYSRESET >>> #define CONFIG_HW_WATCHDOG >>> #endif >> >> Can't we add DM watchdog to SPL instead ? > > Do you mean implementing SPL_DM support for this board so that we can > use the DM watchdog and sysreset? Isn't SPL DM already implemented ? [...] ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
Hi Vasily, I think this should not be needed, see comments below. Hi Philipp, Klaus and Christoph: Could you help to check why do you need below patch for your board? ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset I think we don't need this workaround for rk3399 CPU_B voltage supply, and here is what I got: - rockchip use cru glb_rst_1 for reboot in kernel; - the glb_rst_1 will reset all the GPIO logic to default state; - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which may be a pull up/down IO, - the syr83x output with the hardware default state of the VSEL(with RK3399 default IO output) should be normal output(1.0V), and another state output for suspend(disabled), - In order to make the syr83x works as expected, the kernel setting of syr83x should be correct, check property: fcs,suspend-voltage-selector = <1>; This is correct for rockpro64(vsel connect to a gpio with default pull down) on upstream, but I don't have a puma schematic, so I don't know if this is correct for puma. - With correct setting in syr83x, the cpu_b should always have power supply after reboot/reset with cru glb_rst_1 reg. So no workaround is needed in U-Boot, please correct me if anything is missing. Thanks, - Kever On 2019/11/28 下午2:14, Vasily Khoruzhick wrote: Rockpro64 doesn't boot reliably after soft reset, so let's force power on reset by asserting sysreset pin if we detected soft reset. Signed-off-by: Vasily Khoruzhick --- arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 configs/rockpro64-rk3399_defconfig| 1 + 2 files changed, 9 insertions(+) diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi index 4648513ea9..bb94bcf7be 100644 --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi @@ -6,11 +6,19 @@ #include "rk3399-u-boot.dtsi" #include "rk3399-sdram-lpddr4-100.dtsi" / { + config { + sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>; + }; + chosen { u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci; }; }; +&gpio1 { + u-boot,dm-pre-reloc; +}; + &vdd_center { regulator-min-microvolt = <95>; regulator-max-microvolt = <95>; diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig index 49e27c91cb..d153ac5485 100644 --- a/configs/rockpro64-rk3399_defconfig +++ b/configs/rockpro64-rk3399_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_GPIO_SUPPORT=y CONFIG_ROCKCHIP_RK3399=y CONFIG_ENV_OFFSET=0x3F8000 CONFIG_TARGET_ROCKPRO64_RK3399=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: reset: use do_reset in SPL/TPL if SYSRESET was not enabled for them
On 11/28/19 9:56 AM, Claudius Heine wrote: > In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available > anywere, even if SYSRESET is disabled for SPL/TPL. > > 'do_reset' is called from SPL for instance from the panic handler and > PANIC_HANG is not set > > Signed-off-by: Claudius Heine Reviewed-by: Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Using sspi for hardware detection?
On Thu, Nov 28, 2019 at 10:03 AM Romain Naour wrote: > > Hi, > > Le 27/11/2019 à 21:13, Simon Goldschmidt a écrit : > > On Wed, Nov 27, 2019 at 1:58 PM Romain Naour wrote: > >> > >> Hello, > >> > >> I'm working on a modular socfpga based system with several optional boards. > >> Each optional board contain a board ID that can be read through a SPI bus. > >> > >> Since we want just read the board ID, we used manually the sspi command, > >> something like: > >> > >> => sspi 1:1.0 8 0 > >> 42 > >> > >> But it seems that the sspi command can't be used in a uboot script. sspi > >> seems > >> only used to manually test spi drivers. > >> > >> > >> If we compare with i2c command, we have a i2c read to memory: > >> > >> i2c read chip address[.0, .1, .2] length memaddress - read to memory > >> > >> Why there is no such feature for spi ? > > > > Probably because noone has needed it so far. > > > >> Is there an interest to evolve the sspi command to add a read to memory? > >> > >> sspi : . > > > > If you need it and provide a decent patch, I could probable get accepted... > > Ok I'll take a look how to implement this. > > > > >> > >> By looking at existing code, it seems that hardware detection in uboot is > >> handled by architecture/board specific code to set custom environment > >> variable > >> like "fpgatype" [1] or "unit_ident" "unit_serial" [2] (misc_init_r). > >> > >> What do you recommend? > >> Implement a custom misc_init_r() for hardware detection? > > > > How is that related? How does reading to memory help you with knowing the hw > > type in scripts? > > Sorry, actually this is another possibility. > > The first possibility is evolve the sspi command to add . This > allow > to use a script working on memory containing the data received from the spi > bus. > For my use case, it would allow to get the board ID in memory and use an uboot > script analyze which board ID has been read. > > The second possibility is to use misc_init_r (or as you suggest > board_late_init) > in a board specific code (board///socfpga.c) to access > the > spi bus and set custom environment variable. These environment variable are > later used by uboot script. > > I would like an advice on the best implementation. > I believe modifying sspi command can be the way to go since it can be used for > other use case. Yes, looks to me like that might be a handy thing to have in that command. Of course that comes at the expand of size increasement when this command is compiled in, so I can't judge if it's ok to add. Regards, Simon > > > > > Anyway, I think board_late_init is a better fit than misc_init_r, > > which is rather > > meant to be a platform thing and vining can only use it because socfpga > > doesn't need it otherwise. > > Thanks for your feed back! > > Best regards, > Romain > > > > > > Regards, > > Simon > > > >> > >> [1] > >> https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/misc_gen5.c#L139 > >> [2] > >> https://gitlab.denx.de/u-boot/u-boot/blob/master/board/softing/vining_fpga/socfpga.c#L48 > >> > >> Best regards, > >> Romain > >> ___ > >> 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] ARM: reset: use do_reset in SPL/TPL if SYSRESET was not enabled for them
On Thu, Nov 28, 2019 at 9:57 AM Claudius Heine wrote: > > In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available > anywere, even if SYSRESET is disabled for SPL/TPL. > > 'do_reset' is called from SPL for instance from the panic handler and > PANIC_HANG is not set > > Signed-off-by: Claudius Heine > --- > arch/arm/lib/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > index 9de9a9acee..7bf2c077ba 100644 > --- a/arch/arm/lib/Makefile > +++ b/arch/arm/lib/Makefile > @@ -56,7 +56,7 @@ obj-y += interrupts_64.o > else > obj-y += interrupts.o > endif > -ifndef CONFIG_SYSRESET > +ifndef CONFIG_$(SPL_TPL_)SYSRESET Would it work to do this: obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += reset.o that would be nicer than ifndef, I think. Regards, Simon > obj-y += reset.o > endif > > -- > 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] rockchip: px30: Fixup PMUGRF registers layout order
On 2019/11/27 下午6:12, Paul Kocialkowski wrote: According to the PX30 TRM, the iomux registers come first, before the pull and strength control registers. Signed-off-by: Paul Kocialkowski Reviewed-by: Kever Yang Thanks, - Kever --- arch/arm/include/asm/arch-rockchip/grf_px30.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/grf_px30.h b/arch/arm/include/asm/arch-rockchip/grf_px30.h index c167bb42fac9..3d2a8770322e 100644 --- a/arch/arm/include/asm/arch-rockchip/grf_px30.h +++ b/arch/arm/include/asm/arch-rockchip/grf_px30.h @@ -112,18 +112,18 @@ struct px30_grf { check_member(px30_grf, mac_con1, 0x904); struct px30_pmugrf { - unsigned int gpio0a_e; - unsigned int gpio0b_e; - unsigned int gpio0c_e; - unsigned int gpio0d_e; - unsigned int gpio0a_p; - unsigned int gpio0b_p; - unsigned int gpio0c_p; - unsigned int gpio0d_p; unsigned int gpio0al_iomux; unsigned int gpio0bl_iomux; unsigned int gpio0cl_iomux; unsigned int gpio0dl_iomux; + unsigned int gpio0a_p; + unsigned int gpio0b_p; + unsigned int gpio0c_p; + unsigned int gpio0d_p; + unsigned int gpio0a_e; + unsigned int gpio0b_e; + unsigned int gpio0c_e; + unsigned int gpio0d_e; unsigned int gpio0l_sr; unsigned int gpio0h_sr; unsigned int gpio0l_smt; ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: px30: Add support for using UART3 as debug UART
On 2019/11/27 下午6:12, Paul Kocialkowski wrote: Some generic PX30 SoMs found in the wild use UART3 as their debug output instead of UART2 (used for MMC) and UART5. Make it possible to use UART3 as early debug output, with the associated clock and pinmux configuration. Two sets of output pins are supported (M0/M1) so a Kconfig option to select between the two is introduced like it's done for UART2. Future users should also note that the pinmux default in the dts is to use the M1 pins while the Kconfig option takes M0 as a default. Signed-off-by: Paul Kocialkowski Reviewed-by: Kever Yang Thanks, - Kever --- arch/arm/include/asm/arch-rockchip/cru_px30.h | 19 + arch/arm/mach-rockchip/px30/Kconfig | 9 +++ arch/arm/mach-rockchip/px30/px30.c| 77 +++ 3 files changed, 105 insertions(+) diff --git a/arch/arm/include/asm/arch-rockchip/cru_px30.h b/arch/arm/include/asm/arch-rockchip/cru_px30.h index 7d9fd181aca2..798444ae49f5 100644 --- a/arch/arm/include/asm/arch-rockchip/cru_px30.h +++ b/arch/arm/include/asm/arch-rockchip/cru_px30.h @@ -357,6 +357,25 @@ enum { UART2_DIVNP5_SHIFT = 0, UART2_DIVNP5_MASK = 0x1f << UART2_DIVNP5_SHIFT, + /* CRU_CLK_SEL40_CON */ + UART3_PLL_SEL_SHIFT = 14, + UART3_PLL_SEL_MASK = 3 << UART3_PLL_SEL_SHIFT, + UART3_PLL_SEL_GPLL = 0, + UART3_PLL_SEL_24M, + UART3_PLL_SEL_480M, + UART3_PLL_SEL_NPLL, + UART3_DIV_CON_SHIFT = 0, + UART3_DIV_CON_MASK = 0x1f << UART3_DIV_CON_SHIFT, + + /* CRU_CLK_SEL41_CON */ + UART3_CLK_SEL_SHIFT = 14, + UART3_CLK_SEL_MASK = 3 << UART3_PLL_SEL_SHIFT, + UART3_CLK_SEL_UART3 = 0, + UART3_CLK_SEL_UART3_NP5, + UART3_CLK_SEL_UART3_FRAC, + UART3_DIVNP5_SHIFT = 0, + UART3_DIVNP5_MASK = 0x1f << UART3_DIVNP5_SHIFT, + /* CRU_CLK_SEL46_CON */ UART5_PLL_SEL_SHIFT = 14, UART5_PLL_SEL_MASK = 3 << UART5_PLL_SEL_SHIFT, diff --git a/arch/arm/mach-rockchip/px30/Kconfig b/arch/arm/mach-rockchip/px30/Kconfig index 109a37be15ad..167517bbd63f 100644 --- a/arch/arm/mach-rockchip/px30/Kconfig +++ b/arch/arm/mach-rockchip/px30/Kconfig @@ -36,6 +36,15 @@ config DEBUG_UART2_CHANNEL For using the UART for early debugging the route to use needs to be declared (0 or 1). +config DEBUG_UART3_CHANNEL + int "Mux channel to use for debug UART3" + depends on DEBUG_UART_BOARD_INIT + default 0 + help + UART3 can use two different set of pins to route the output. + For using the UART for early debugging the route to use needs + to be declared (0 or 1). + source "board/rockchip/evb_px30/Kconfig" endif diff --git a/arch/arm/mach-rockchip/px30/px30.c b/arch/arm/mach-rockchip/px30/px30.c index bacdcc0b938d..6b12f4f6a502 100644 --- a/arch/arm/mach-rockchip/px30/px30.c +++ b/arch/arm/mach-rockchip/px30/px30.c @@ -37,6 +37,7 @@ static struct mm_region px30_mem_map[] = { struct mm_region *mem_map = px30_mem_map; #define PMU_PWRDN_CON 0xff18 +#define PMUGRF_BASE0xff01 #define GRF_BASE 0xff14 #define CRU_BASE 0xff2b #define VIDEO_PHY_BASE0xff2e @@ -49,6 +50,23 @@ struct mm_region *mem_map = px30_mem_map; #define QOS_PRIORITY_LEVEL(h, l) h) & 3) << 8) | ((l) & 3)) +/* GRF_GPIO1BH_IOMUX */ +enum { + GPIO1B7_SHIFT = 12, + GPIO1B7_MASK= 0xf << GPIO1B7_SHIFT, + GPIO1B7_GPIO= 0, + GPIO1B7_FLASH_RDN, + GPIO1B7_UART3_RXM1, + GPIO1B7_SPI0_CLK, + + GPIO1B6_SHIFT = 8, + GPIO1B6_MASK= 0xf << GPIO1B6_SHIFT, + GPIO1B6_GPIO= 0, + GPIO1B6_FLASH_CS1, + GPIO1B6_UART3_TXM1, + GPIO1B6_SPI0_CSN, +}; + /* GRF_GPIO1CL_IOMUX */ enum { GPIO1C1_SHIFT = 4, @@ -128,6 +146,23 @@ enum { GPIO3A1_UART5_RX= 4, }; +/* PMUGRF_GPIO0CL_IOMUX */ +enum { + GPIO0C1_SHIFT = 2, + GPIO0C1_MASK= 0x3 << GPIO0C1_SHIFT, + GPIO0C1_GPIO= 0, + GPIO0C1_PWM_3, + GPIO0C1_UART3_RXM0, + GPIO0C1_PMU_DEBUG4, + + GPIO0C0_SHIFT = 0, + GPIO0C0_MASK= 0x3 << GPIO0C0_SHIFT, + GPIO0C0_GPIO= 0, + GPIO0C0_PWM_1, + GPIO0C0_UART3_TXM0, + GPIO0C0_PMU_DEBUG3, +}; + int arch_cpu_init(void) { static struct px30_grf * const grf = (void *)GRF_BASE; @@ -175,6 +210,11 @@ int arch_cpu_init(void) #ifdef CONFIG_DEBUG_UART_BOARD_INIT void board_debug_uart_init(void) { +#if defined(CONFIG_DEBUG_UART_BASE) && \ + (CONFIG_DEBUG_UART_BASE == 0xff168000) && \ + (CONFIG_DEBUG_UART3_CHANNEL != 1) + static struct px30_pmugrf * const pmugrf = (void *)PMUGRF_BASE; +#en
Re: [U-Boot] [PATCH 1/2] rockchip: rk3399: fix force power on reset
On 2019/11/28 下午2:14, Vasily Khoruzhick wrote: Currently code doesn't even compile since it uses wrong define for ifdef. Fix that and also add missing include Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init") Signed-off-by: Vasily Khoruzhick Reviewed-by: Kever Yang Thanks, - Kever --- arch/arm/mach-rockchip/rk3399/rk3399.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 863024d071..eeb99dd11b 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -213,7 +214,7 @@ void spl_perform_fixups(struct spl_image_info *spl_image) "u-boot,spl-boot-device", boot_ofpath); } -#if defined(SPL_GPIO_SUPPORT) +#if defined(CONFIG_SPL_GPIO_SUPPORT) static void rk3399_force_power_on_reset(void) { ofnode node; @@ -239,7 +240,7 @@ static void rk3399_force_power_on_reset(void) void spl_board_init(void) { -#if defined(SPL_GPIO_SUPPORT) +#if defined(CONFIG_SPL_GPIO_SUPPORT) struct rk3399_cru *cru = rockchip_get_cru(); /* ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GPT overlap on i.MX6
Hi Jagan, > Hi Lukasz, > > On Wed, Nov 27, 2019 at 9:47 PM Lukasz Majewski wrote: > > > > Hi Jagan, > > > > > Hi Lukasz, > > > > > > On Wed, Nov 27, 2019 at 4:15 PM Lukasz Majewski > > > wrote: > > > > > > > > Hi Jagan, > > > > > > > > > Hi, > > > > > > > > > > I have created GPT table start from 8MB for kernel, roots etc. > > > > > something like > > > > > > > > > > PartStart LBA End LBA Name > > > > > Attributes > > > > > Type GUID > > > > > Partition GUID > > > > > 1 0x4000 0x00023fff "boota" > > > > > attrs: 0x0004 > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > > > 2 0x00024000 0x00043fff "bootb" > > > > > attrs: 0x0004 > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: 21686148-6449-6e6f-744e-656564454649 > > > > > 3 0x00044000 0x00243fff "rootfsa" > > > > > attrs: 0x > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > > > > 4 0x00244000 0x00443fff "rootfsb" > > > > > attrs: 0x > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > > > > 5 0x00444000 0x0070bfde "data" > > > > > attrs: 0x > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > > > > > > > I have not included SPL, U-Boot to the partition list since it > > > > > start from 0x400 in i.MX6. So > > > > > I'm writing SPL separately using fastboot(with offset) or ums. > > > > > > > > > > But by doing this, the partition header seems overlapped so > > > > > the output looks > > > > > > > > > > GUID Partition Table Entry Array CRC is wrong: 0x6a1aba0a != > > > > > 0x8e4fd548 find_valid_gpt: *** ERROR: Invalid GPT *** > > > > > find_valid_gpt: ***Using Backup GPT *** > > > > > PartStart LBA End LBA Name > > > > > Attributes > > > > > Type GUID > > > > > Partition GUID > > > > > 1 0x4000 0x00023fff "boota" > > > > > attrs: 0x0004 > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > > > 2 0x00024000 0x00043fff "bootb" > > > > > attrs: 0x0004 > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: 21686148-6449-6e6f-744e-656564454649 > > > > > 3 0x00044000 0x00243fff "rootfsa" > > > > > attrs: 0x > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > > > > 4 0x00244000 0x00443fff "rootfsb" > > > > > attrs: 0x > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > > > > 5 0x00444000 0x0070bfde "data" > > > > > attrs: 0x > > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > > > > > > > So, what I understand is If I create the GPT first and then > > > > > write the SPL, the SPL writing process will destroy the GPT > > > > > Table and if I write SPL first and then create GPT, the GPT > > > > > creation process will destroy the SPL. > > > > > > > > > > Is there any way to fix this? I remember we can prevent this > > > > > overlap by preserving GPT Table som other or boot partition > > > > > instead of having them at the beginning by default. > > > > > > > > > > Any inputs? > > > > > > > > On the diagram of GPT description [1] there is the info that > > > > partitions can start from LBA 34 (0x200 * 34) = 0x4400 > > > > > > > > From the above it seems like you starts from 0x4000 your boota > > > > partition, which then overwrites the "Entries 5-128" which > > > > shall be 0 and are protected by CRC written in the Primary GPT > > > > Header. > > > > > > > > Please try to adjust your partition scheme to start from > > > > 0x4400. > > > > > > I still see the overlap. I have created boota at 0x4400 and the > > > write the SPL at 0x400 > > ^^ - this overwrites the GPT header IMHO. > > True, this overlap GPT. and we don't have an option since ROM > expecting the SPL at 0x400. The ROM expects some LBA from eMMC being accessible. Maybe it would be possible to add some specific for your application DCD code to enable eMMC's boot{01} partition? Also IIRC i.MX6 allows playing around with some fuses, so maybe you can specify eMMC to use boot{01} HW partition?
Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
On 11/28/19 7:22 AM, Heinrich Schuchardt wrote: > On 11/26/19 6:07 PM, Marek Vasut wrote: >> On 11/26/19 5:52 PM, Tom Rini wrote: >>> On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote: On 11/26/19 5:26 PM, Tom Rini wrote: > On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote: >> On 11/26/19 12:16 AM, Heinrich Schuchardt wrote: >>> Dear maintainers, >> >> Hi, >> >>> we have been trying to move to the driver model for several years >>> now. >>> Starting in 2018 we have added warnings to the Makefile that >>> boards not >>> supporting the driver model will be eliminated. Still 24 % of the >>> configuration files have not been converted and do not even use >>> CONFIG_DM=y. >>> >>> If we want to get rid of legacy drivers, at some point we have to >>> remove >>> the 347 configuration files in the list below not using the >>> driver model. >>> >>> I suggest to do this directly after the release of v2020.01 >>> scheduled >>> January 6th. >>> >>> This should not stop the maintainers from reinserting the boards >>> after >>> conversion to the driver model. >> >> Some boards just cannot accommodate this DM stuff. For those boards, >> it's just bloat without any useful added value. Hence, these boards >> would be removed because they cannot accommodate arbitrary bloat. >> This >> makes U-Boot not-so-universal bootloader anymore, but rather a >> bloated one. >> >> I don't think we can force boards out or impose DM on everyone >> unless we >> can solve this bloat issue first. > > As someone who was involved in creating this DM stuff, do you have > some > ideas on addressing things? Given that you're responsible for a > number > of these platforms and can test out some ideas on them, what are you > suggesting? How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that. >>> >>> And when are you hoping to post an RFC / example? >> >> Currently I have zero time available. Maybe someone else can look into >> this option? > > Dear Marex, > > DM drivers make use of the DM infrastructure for instance for the > allocation of the private data area. The uclass files often include > common logic needed for accessing all drivers (see for example tpm_xfer()). > > So which drivers do you think of that could be simplified? UART for example ? You only usually have one. > I would also be interested to learn which of the 347 boards not using > CONFIG_DM=y are still actively maintained. Probably quite a few of those iMX, omap and PPC ones. The qemu ones are probably used for CI ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: px30: Add support for using UART3 as debug UART
Heiko, > On 28.11.2019, at 10:44, Heiko Stuebner > wrote: > > On 27.11.19 11:12, Paul Kocialkowski wrote: >> Some generic PX30 SoMs found in the wild use UART3 as their debug output >> instead of UART2 (used for MMC) and UART5. >> >> Make it possible to use UART3 as early debug output, with the associated >> clock and pinmux configuration. Two sets of output pins are supported (M0/M1) >> so a Kconfig option to select between the two is introduced like it's done >> for UART2. >> >> Future users should also note that the pinmux default in the dts is to use >> the M1 pins while the Kconfig option takes M0 as a default. >> >> Signed-off-by: Paul Kocialkowski > > Reviewed-by: Heiko Stuebner > > with one small question below > >> diff --git a/arch/arm/mach-rockchip/px30/Kconfig >> b/arch/arm/mach-rockchip/px30/Kconfig >> index 109a37be15ad..167517bbd63f 100644 >> --- a/arch/arm/mach-rockchip/px30/Kconfig >> +++ b/arch/arm/mach-rockchip/px30/Kconfig >> @@ -36,6 +36,15 @@ config DEBUG_UART2_CHANNEL >>For using the UART for early debugging the route to use needs >>to be declared (0 or 1). >> +config DEBUG_UART3_CHANNEL >> +int "Mux channel to use for debug UART3" >> +depends on DEBUG_UART_BOARD_INIT >> +default 0 >> +help >> + UART3 can use two different set of pins to route the output. >> + For using the UART for early debugging the route to use needs >> + to be declared (0 or 1). >> + >> source "board/rockchip/evb_px30/Kconfig" > > Would it make sense to rename DEBUG_UART3_CHANNEL to just > DEBUG_UART_CHANNEL and reuse it, so that we don't collect similar > options for each uart? Let me also check what we use on the Jaguar platform, as that will be our baseline platform for PX30 support for TSD boards... Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: px30: Add support for using UART3 as debug UART
Hi Heiko, On Thu 28 Nov 19, 10:44, Heiko Stuebner wrote: > On 27.11.19 11:12, Paul Kocialkowski wrote: > > Some generic PX30 SoMs found in the wild use UART3 as their debug output > > instead of UART2 (used for MMC) and UART5. > > > > Make it possible to use UART3 as early debug output, with the associated > > clock and pinmux configuration. Two sets of output pins are supported > > (M0/M1) > > so a Kconfig option to select between the two is introduced like it's done > > for UART2. > > > > Future users should also note that the pinmux default in the dts is to use > > the M1 pins while the Kconfig option takes M0 as a default. > > > > Signed-off-by: Paul Kocialkowski > > Reviewed-by: Heiko Stuebner > > with one small question below > > > diff --git a/arch/arm/mach-rockchip/px30/Kconfig > > b/arch/arm/mach-rockchip/px30/Kconfig > > index 109a37be15ad..167517bbd63f 100644 > > --- a/arch/arm/mach-rockchip/px30/Kconfig > > +++ b/arch/arm/mach-rockchip/px30/Kconfig > > @@ -36,6 +36,15 @@ config DEBUG_UART2_CHANNEL > > For using the UART for early debugging the route to use needs > > to be declared (0 or 1). > > +config DEBUG_UART3_CHANNEL > > + int "Mux channel to use for debug UART3" > > + depends on DEBUG_UART_BOARD_INIT > > + default 0 > > + help > > + UART3 can use two different set of pins to route the output. > > + For using the UART for early debugging the route to use needs > > + to be declared (0 or 1). > > + > > source "board/rockchip/evb_px30/Kconfig" > > Would it make sense to rename DEBUG_UART3_CHANNEL to just > DEBUG_UART_CHANNEL and reuse it, so that we don't collect similar > options for each uart? Yes I like that better too. Will craft a v2 with that. And thanks for the review! Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-socfpga/master
The following changes since commit 9a0cbae22a613dfd55e15565785749b74c19fdf0: Merge tag 'u-boot-rockchip-20191124' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip (2019-11-23 20:50:11 -0500) are available in the Git repository at: git://git.denx.de/u-boot-socfpga.git master for you to fetch changes up to a1a9843a29672be49a5bbb3a07fea8dbc88369ba: ARM: socfpga: Unreset NAND in SPL on Gen5 (2019-11-25 13:12:56 +0100) Marek Vasut (5): ARM: socfpga: Actually put bridges into reset on Gen5 in bridge disable ARM: socfpga: Purge pending transactions upon enabling bridges on Gen5 ARM: socfpga: Add ArriaV ST/SX ID ARM: socfpga: Introduce u-boot-with-nand-spl.sfp target ARM: socfpga: Unreset NAND in SPL on Gen5 Makefile | 11 +++ arch/arm/mach-socfpga/misc_gen5.c | 7 ++- arch/arm/mach-socfpga/spl_gen5.c | 7 +++ 3 files changed, 24 insertions(+), 1 deletion(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 9a0cbae22a613dfd55e15565785749b74c19fdf0: Merge tag 'u-boot-rockchip-20191124' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip (2019-11-23 20:50:11 -0500) are available in the Git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to dbcbdad92caf4b42a6279da6e65180532bc45620: sandbox: enable USB_KEYBOARD_FN_KEYS (2019-11-25 13:28:53 +0100) Heinrich Schuchardt (7): usb: kbd: fix typo usb: kbd: signature of usb_kbd_put_queue() usb: kbd: simplify coding for arrow keys usb: kbd: implement special keys usb: kbd: move USB_KBD_BOOT_REPORT_SIZE to usb.h dm: test: usb: rework keyboard test sandbox: enable USB_KEYBOARD_FN_KEYS common/usb_kbd.c | 97 +++--- configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + drivers/usb/Kconfig| 6 +++ drivers/usb/emul/sandbox_keyb.c| 27 ++ include/usb.h | 6 +++ test/dm/usb.c | 284 +++--- 9 files changed, 364 insertions(+), 60 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools/imximage: fix reported DCD information for MX7ULP
On the MX7ULP, OCRAM for DCD is at 0x2f01 Signed-off-by: Jorge Ramirez-Ortiz --- tools/imximage.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/imximage.c b/tools/imximage.c index d7c0b6e883..762a06d468 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -11,6 +11,7 @@ #include "imagetool.h" #include #include "imximage.h" +#include #define UNDEFINED 0x @@ -524,8 +525,13 @@ static void print_hdr_v2(struct imx_header *imx_hdr) printf("HAB Blocks: 0x%08x 0x%08x 0x%08x\n", (uint32_t)fhdr_v2->self, 0, (uint32_t)(fhdr_v2->csf - fhdr_v2->self)); +#ifndef CONFIG_MX7ULP printf("DCD Blocks: 0x0091 0x%08x 0x%08x\n", offs, be16_to_cpu(dcdlen)); +#else + printf("DCD Blocks: 0x2f01 0x%08x 0x%08x\n", + offs, be16_to_cpu(dcdlen)); +#endif } } else { imx_header_v2_t *next_hdr_v2; -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: reset: use do_reset in SPL/TPL if SYSRESET was not enabled for them
On 28/11/2019 10.27, Simon Goldschmidt wrote: > On Thu, Nov 28, 2019 at 9:57 AM Claudius Heine wrote: >> >> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available >> anywere, even if SYSRESET is disabled for SPL/TPL. >> >> 'do_reset' is called from SPL for instance from the panic handler and >> PANIC_HANG is not set >> >> Signed-off-by: Claudius Heine >> --- >> arch/arm/lib/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile >> index 9de9a9acee..7bf2c077ba 100644 >> --- a/arch/arm/lib/Makefile >> +++ b/arch/arm/lib/Makefile >> @@ -56,7 +56,7 @@ obj-y += interrupts_64.o >> else >> obj-y += interrupts.o >> endif >> -ifndef CONFIG_SYSRESET >> +ifndef CONFIG_$(SPL_TPL_)SYSRESET > > Would it work to do this: > obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += reset.o > > that would be nicer than ifndef, I think. Yes it would, but it didn't seem to work. With: diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 9416369aad..913bb21eaf 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -56,9 +56,7 @@ obj-y += interrupts_64.o else obj-y += interrupts.o endif -ifndef CONFIG_(SPL_TPL_)SYSRESET -obj-y += reset.o -endif +obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += reset.o obj-y += cache.o obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o I get with CONFIG_SYSRESET: arm-linux-gnu-ld.bfd: drivers/built-in.o: in function `do_reset': drivers/sysreset/sysreset-uclass.c:113: multiple definition of `do_reset'; arch/arm/lib/built-in.o:arch/arm/lib/reset.c:30: first defined here make: *** [Makefile:1667: u-boot] Error 1 And without CONFIG_SYSRESET: arm-linux-gnu-ld.bfd: lib/built-in.o: in function `efi_reset_system_boottime': lib/efi_loader/efi_runtime.c:165: undefined reference to `do_reset' arm-linux-gnu-ld.bfd: lib/built-in.o: in function `panic_finish': lib/panic.c:26: undefined reference to `do_reset' arm-linux-gnu-ld.bfd: arch/arm/mach-imx/built-in.o: in function `do_boot_mode': arch/arm/mach-imx/cmd_bmode.c:76: undefined reference to `do_reset' arm-linux-gnu-ld.bfd: cmd/built-in.o:(.u_boot_list_2_cmd_2_reset+0xc): undefined reference to `do_reset' arm-linux-gnu-ld.bfd: common/built-in.o: in function `jumptable_init': common/exports.c:30: undefined reference to `do_reset' arm-linux-gnu-ld.bfd: common/built-in.o: in function `print_resetinfo': common/board_f.c:167: undefined reference to `sysreset_get_status' arm-linux-gnu-ld.bfd: common/built-in.o: in function `do_bootm_states': common/bootm.c:633: undefined reference to `do_reset' arm-linux-gnu-ld.bfd: common/built-in.o: in function `run_usb_dnl_gadget': common/dfu.c:90: undefined reference to `do_reset' make: *** [Makefile:1667: u-boot] Error 1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-boot] regression: bootaux doesn't work with DCACHE enabled
Hi all, U-boot imx-specific bootaux command doesn't work properly with the old legacy binary format if the DCACHE is enabled (I've tested only executing from OCRAM) in the mainline U-boot. Interesting thing is that invocation of `dcache flush` before bootaux doesn't help, but only full disabling it with `dcache off`. To reproduce: > tftpboot ${loadaddr} ${board_name}/hello_world.bin > cp.b ${loadaddr} 0x7F8000 $filesize > bootaux 0x7F8000 However this works: > tftpboot ${loadaddr} ${board_name}/hello_world.bin > cp.b ${loadaddr} 0x7F8000 $filesize > dcache off > bootaux 0x7F8000 Any ideas and suggestions? Thanks -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: reset: use do_reset in SPL/TPL if SYSRESET was not enabled for them
On Thu, Nov 28, 2019 at 11:52 AM Claudius Heine wrote: > > On 28/11/2019 10.27, Simon Goldschmidt wrote: > > On Thu, Nov 28, 2019 at 9:57 AM Claudius Heine wrote: > >> > >> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available > >> anywere, even if SYSRESET is disabled for SPL/TPL. > >> > >> 'do_reset' is called from SPL for instance from the panic handler and > >> PANIC_HANG is not set > >> > >> Signed-off-by: Claudius Heine > >> --- > >> arch/arm/lib/Makefile | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > >> index 9de9a9acee..7bf2c077ba 100644 > >> --- a/arch/arm/lib/Makefile > >> +++ b/arch/arm/lib/Makefile > >> @@ -56,7 +56,7 @@ obj-y += interrupts_64.o > >> else > >> obj-y += interrupts.o > >> endif > >> -ifndef CONFIG_SYSRESET > >> +ifndef CONFIG_$(SPL_TPL_)SYSRESET > > > > Would it work to do this: > > obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += reset.o > > > > that would be nicer than ifndef, I think. > > Yes it would, but it didn't seem to work. OK, thanks for trying. Given the results below, it's fine for me, so: Reviewed-by: Simon Goldschmidt > > With: > > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > index 9416369aad..913bb21eaf 100644 > --- a/arch/arm/lib/Makefile > +++ b/arch/arm/lib/Makefile > @@ -56,9 +56,7 @@ obj-y += interrupts_64.o > else > obj-y += interrupts.o > endif > -ifndef CONFIG_(SPL_TPL_)SYSRESET > -obj-y += reset.o > -endif > +obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += reset.o > > obj-y += cache.o > obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o > > I get with CONFIG_SYSRESET: > > arm-linux-gnu-ld.bfd: drivers/built-in.o: in function `do_reset': > drivers/sysreset/sysreset-uclass.c:113: multiple definition of > `do_reset'; arch/arm/lib/built-in.o:arch/arm/lib/reset.c:30: first > defined here > make: *** [Makefile:1667: u-boot] Error 1 > > And without CONFIG_SYSRESET: > > arm-linux-gnu-ld.bfd: lib/built-in.o: in function > `efi_reset_system_boottime': > lib/efi_loader/efi_runtime.c:165: undefined reference to `do_reset' > arm-linux-gnu-ld.bfd: lib/built-in.o: in function `panic_finish': > lib/panic.c:26: undefined reference to `do_reset' > arm-linux-gnu-ld.bfd: arch/arm/mach-imx/built-in.o: in function > `do_boot_mode': > arch/arm/mach-imx/cmd_bmode.c:76: undefined reference to `do_reset' > arm-linux-gnu-ld.bfd: cmd/built-in.o:(.u_boot_list_2_cmd_2_reset+0xc): > undefined reference to `do_reset' > arm-linux-gnu-ld.bfd: common/built-in.o: in function `jumptable_init': > common/exports.c:30: undefined reference to `do_reset' > arm-linux-gnu-ld.bfd: common/built-in.o: in function `print_resetinfo': > common/board_f.c:167: undefined reference to `sysreset_get_status' > arm-linux-gnu-ld.bfd: common/built-in.o: in function `do_bootm_states': > common/bootm.c:633: undefined reference to `do_reset' > arm-linux-gnu-ld.bfd: common/built-in.o: in function `run_usb_dnl_gadget': > common/dfu.c:90: undefined reference to `do_reset' > make: *** [Makefile:1667: u-boot] Error 1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: Allow cache drivers to be used in SPL
On Thu, Nov 28, 2019 at 1:59 AM Ley Foon Tan wrote: > > On Thu, Nov 28, 2019 at 4:33 AM Simon Goldschmidt > wrote: > > > > Ley, Tom, > > > > Am 26.11.2019 um 10:26 schrieb Ley Foon Tan: > > > On Fri, Nov 8, 2019 at 10:53 AM Ley Foon Tan > > > wrote: > > >> > > >> Add an option for building cache drivers in SPL. > > > > Ley: > > > > What's the actual problem here? Can you further describe your change? > > Why do you need to change drivers/cache/Makefile? That seems to only > > make sense if you enable the new SPL_CACHE without (non-SPL) CACHE. > > > > However, the series this was pulled out from adds a new cache driver and > > makes it select CACHE, not SPL_CACHE, so how would this be activated anyway? > > > > Maybe it would be better to always dive down into drivers/cache/ if > > CACHE is y? > Hi Simon > > The existing drivers/cache is only build when compile for Uboot > proper, but not SPL build. > So, this patch mainly is to allow drivers/cache to compile in SPL build. > User can enable CONFIG_SPL_CACHE if they need to include drivers/cache > in SPL, eg: Agilex platform. But you might not have CACHE enabled since you can enable SPL_CACHE without CACHE, see my suggestions below. > > Regards > Ley Foon > > > > > Tom: > > > > As drivers/cache is rather new and initiated via the socfpga tree, would > > you be OK for us to take this via the socfpga/next tree once it's sorted > > out? > > > > Regards, > > Simon > > > > >> > > >> Signed-off-by: Ley Foon Tan > > >> --- > > >> common/spl/Kconfig | 5 + > > >> drivers/Makefile | 1 + > > >> drivers/cache/Makefile | 2 +- > > >> 3 files changed, 7 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > >> index c661809923..6e095c33e1 100644 > > >> --- a/common/spl/Kconfig > > >> +++ b/common/spl/Kconfig > > >> @@ -714,6 +714,11 @@ config SPL_UBI > > >>README.ubispl for more info. > > >> > > >> if SPL_DM > > >> +config SPL_CACHE > > >> + bool "Support cache drivers in SPL" I think this needs to depend on CACHE. > > >> + help > > >> + Enable support for cache drivers in SPL. > > >> + > > >> config SPL_DM_SPI > > >> bool "Support SPI DM drivers in SPL" > > >> help > > >> diff --git a/drivers/Makefile b/drivers/Makefile > > >> index 0befeddfcb..0e42d006b9 100644 > > >> --- a/drivers/Makefile > > >> +++ b/drivers/Makefile > > >> @@ -31,6 +31,7 @@ ifndef CONFIG_TPL_BUILD > > >> ifdef CONFIG_SPL_BUILD > > >> > > >> obj-$(CONFIG_SPL_BOOTCOUNT_LIMIT) += bootcount/ > > >> +obj-$(CONFIG_SPL_CACHE) += cache/ Can you move this up to the common part and make it: obj-$(CONFIG_$(SPL_TPL_)CACHE) += cache/ > > >> obj-$(CONFIG_SPL_CPU_SUPPORT) += cpu/ > > >> obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/ > > >> obj-$(CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT) += ddr/fsl/ > > >> diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile > > >> index 4a6458c602..c1f766cfca 100644 > > >> --- a/drivers/cache/Makefile > > >> +++ b/drivers/cache/Makefile > > >> @@ -1,5 +1,5 @@ > > >> > > >> -obj-$(CONFIG_CACHE) += cache-uclass.o > > >> +obj-$(CONFIG_$(SPL_)CACHE) += cache-uclass.o This should then probably be $(SPL_TPL), too? Although we don't have CONFIG_TPL_CACHE, yet, it might be better like that to prevent including cache drivers in TPL? Regards, Simon > > >> obj-$(CONFIG_SANDBOX) += sandbox_cache.o > > >> obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o > > >> obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o > > >> -- > > >> 2.19.0 > > > Hi Tom > > > > > > Any comment on this patch? > > > > > > Regards > > > > > > Ley Foon > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-boot] regression: bootaux doesn't work with DCACHE enabled
On Thu, Nov 28, 2019 at 12:52 PM Igor Opaniuk wrote: > > Hi all, > > U-boot imx-specific bootaux command doesn't work properly > with the old legacy binary format if the DCACHE is enabled (I've > tested only executing from OCRAM) in the mainline U-boot. > > Interesting thing is that invocation of `dcache flush` before bootaux > doesn't help, but only full disabling it with `dcache off`. > > To reproduce: > > tftpboot ${loadaddr} ${board_name}/hello_world.bin > > cp.b ${loadaddr} 0x7F8000 $filesize > > bootaux 0x7F8000 > > However this works: > > tftpboot ${loadaddr} ${board_name}/hello_world.bin > > cp.b ${loadaddr} 0x7F8000 $filesize > > dcache off > > bootaux 0x7F8000 > > Any ideas and suggestions? > Thanks > > -- > Best regards - Freundliche Grüsse - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opan...@gmail.com > skype: igor.opanyuk > +380 (93) 836 40 67 > http://ua.linkedin.com/in/iopaniuk Flushing dcache just after enabling M4 core helps: diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c index 7f4bbfe885..86eb0c7902 100644 --- a/arch/arm/mach-imx/imx_bootaux.c +++ b/arch/arm/mach-imx/imx_bootaux.c @@ -100,6 +100,8 @@ int arch_auxiliary_core_up(u32 core_id, ulong addr) writel(stack, M4_BOOTROM_BASE_ADDR); writel(pc, M4_BOOTROM_BASE_ADDR + 4); + flush_dcache_all(); + /* Enable M4 */ #ifdef CONFIG_IMX8M call_imx_sip(IMX_SIP_SRC, IMX_SIP_SRC_M4_START, 0, 0, 0); Will send a patch soon. -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] ARM: imx6: DHCOM i.MX6 PDK: Fixing reset
Hi, currently the reset on the DHCOM i.MX6 board is brocken in u-boot. This patchset fixes that by integrating the sysreset and watchdog dm driver. regards, Claudius Claudius Heine (4): ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver ARM: imx6: DHCOM i.MX6 PDK: Enable sysreset driver ARM: imx6: DHCOM i.MX6 PDK: Enable wdt command ARM: imx6: DHCOM i.MX6 PDK: Use HW_WATCHDOG in SPL arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + configs/dh_imx6_defconfig| 3 +++ include/configs/dh_imx6.h| 5 + 3 files changed, 13 insertions(+) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Signed-off-by: Claudius Heine --- arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi index af4719aaeb..572bcbf8f0 100644 --- a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi +++ b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi @@ -30,6 +30,11 @@ mux-int-port = <1>; mux-ext-port = <3>; }; + + wdt-reboot { + compatible = "wdt-reboot"; + wdt = <&wdog1>; + }; }; &audmux { -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: imx6: DHCOM i.MX6 PDK: Enable sysreset driver
Signed-off-by: Claudius Heine --- configs/dh_imx6_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig index 4055812007..68dc3b0d1f 100644 --- a/configs/dh_imx6_defconfig +++ b/configs/dh_imx6_defconfig @@ -77,6 +77,8 @@ CONFIG_DM_SCSI=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MXC_SPI=y +CONFIG_SYSRESET=y +CONFIG_SYSRESET_WATCHDOG=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_GADGET=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] ARM: imx6: DHCOM i.MX6 PDK: Use HW_WATCHDOG in SPL
The SPL does not have DM enabled and therefor needs to use the hardware watchdog interface provided by the imx-watchdog driver. Signed-off-by: Claudius Heine --- include/configs/dh_imx6.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h index d4bd88f511..77074aaa06 100644 --- a/include/configs/dh_imx6.h +++ b/include/configs/dh_imx6.h @@ -87,6 +87,11 @@ #endif /* Watchdog */ +#if defined(CONFIG_SPL_BUILD) +#undef CONFIG_WDT +#undef CONFIG_WATCHDOG +#define CONFIG_HW_WATCHDOG +#endif /* allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] ARM: imx6: DHCOM i.MX6 PDK: Enable wdt command
Signed-off-by: Claudius Heine --- configs/dh_imx6_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig index 68dc3b0d1f..e5c44381b2 100644 --- a/configs/dh_imx6_defconfig +++ b/configs/dh_imx6_defconfig @@ -37,6 +37,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_WDT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_EXT4_WRITE=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
On 11/28/19 1:06 PM, Claudius Heine wrote: > Signed-off-by: Claudius Heine > --- > arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > index af4719aaeb..572bcbf8f0 100644 > --- a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > +++ b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > @@ -30,6 +30,11 @@ > mux-int-port = <1>; > mux-ext-port = <3>; > }; > + > + wdt-reboot { > + compatible = "wdt-reboot"; > + wdt = <&wdog1>; > + }; > }; > > &audmux { This should go into separate -u-boot.dtsi , so the base DT can be easily synced with Linux one. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] cmd: pxe: Increase maximum path length
On NixOS, cross compiled kernels have long suffixes that cause them to exceed the current maximum path length. The PXE/TFTP max path length is used for extlinux.conf support as well, which is where this problem usually manifest's itself. Signed-off-by: Ben Wolsieffer --- cmd/pxe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/pxe.c b/cmd/pxe.c index 2059975446..744cd82730 100644 --- a/cmd/pxe.c +++ b/cmd/pxe.c @@ -21,7 +21,7 @@ #include "menu.h" #include "cli.h" -#define MAX_TFTP_PATH_LEN 127 +#define MAX_TFTP_PATH_LEN 512 const char *pxe_default_paths[] = { #ifdef CONFIG_SYS_SOC -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: px30: Add support for using UART3 as debug UART
On 27.11.19 11:12, Paul Kocialkowski wrote: Some generic PX30 SoMs found in the wild use UART3 as their debug output instead of UART2 (used for MMC) and UART5. Make it possible to use UART3 as early debug output, with the associated clock and pinmux configuration. Two sets of output pins are supported (M0/M1) so a Kconfig option to select between the two is introduced like it's done for UART2. Future users should also note that the pinmux default in the dts is to use the M1 pins while the Kconfig option takes M0 as a default. Signed-off-by: Paul Kocialkowski Reviewed-by: Heiko Stuebner with one small question below diff --git a/arch/arm/mach-rockchip/px30/Kconfig b/arch/arm/mach-rockchip/px30/Kconfig index 109a37be15ad..167517bbd63f 100644 --- a/arch/arm/mach-rockchip/px30/Kconfig +++ b/arch/arm/mach-rockchip/px30/Kconfig @@ -36,6 +36,15 @@ config DEBUG_UART2_CHANNEL For using the UART for early debugging the route to use needs to be declared (0 or 1). +config DEBUG_UART3_CHANNEL + int "Mux channel to use for debug UART3" + depends on DEBUG_UART_BOARD_INIT + default 0 + help + UART3 can use two different set of pins to route the output. + For using the UART for early debugging the route to use needs + to be declared (0 or 1). + source "board/rockchip/evb_px30/Kconfig" Would it make sense to rename DEBUG_UART3_CHANNEL to just DEBUG_UART_CHANNEL and reuse it, so that we don't collect similar options for each uart? Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] rockchip: px30: Fixup PMUGRF registers layout order
On 27.11.19 11:12, Paul Kocialkowski wrote: According to the PX30 TRM, the iomux registers come first, before the pull and strength control registers. Signed-off-by: Paul Kocialkowski Reviewed-by: Heiko Stuebner Thanks for that catch Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] usb: Make USB_MUSB_PIO_ONLY selected by USB_MUSB_SUNXI
This ensures the USB_MUSB_PIO_ONLY config is set to an apppropriate value from the changes enabling USB_MUSB_GADGET does. Namely, USB_MUSB_PIO_ONLY default to =y on USB_MUSB_SUNXI being y. Signed-off-by: Samuel Dionne-Riel --- Changes in v2: - Use select as a reverse-dependency As discussed on IRC with Marex, Some additional context about the bug. Using `make ..._defconfig` for a sunxi board, then using `make menuconfig` to change the option `CONFIG_USB_MUSB_GADGET=y` causes builds to fail. When the same option is set to `=y` via the defconfig file, the option work. Follows the failure: ``` CC drivers/usb/musb-new/musb_gadget.o drivers/usb/musb-new/musb_gadget.c: In function 'map_dma_buffer': drivers/usb/musb-new/musb_gadget.c:103:26: warning: implicit declaration of function 'dma_map_single'; did you mean 'malloc_simple'? [-Wimplicit-function-declaration] request->request.dma = dma_map_single( ^~ malloc_simple drivers/usb/musb-new/musb_gadget.c:108:8: error: 'DMA_TO_DEVICE' undeclared (first use in this function); did you mean 'USB_DT_DEVICE'? ? DMA_TO_DEVICE ^ USB_DT_DEVICE drivers/usb/musb-new/musb_gadget.c:108:8: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/musb-new/musb_gadget.c:109:8: error: 'DMA_FROM_DEVICE' undeclared (first use in this function); did you mean 'U_BOOT_DEVICE'? : DMA_FROM_DEVICE); ^~~ U_BOOT_DEVICE drivers/usb/musb-new/musb_gadget.c:112:3: warning: implicit declaration of function 'dma_sync_single_for_device' [-Wimplicit-function-declaration] dma_sync_single_for_device(musb->controller, ^~ drivers/usb/musb-new/musb_gadget.c: In function 'unmap_dma_buffer': drivers/usb/musb-new/musb_gadget.c:135:3: warning: implicit declaration of function 'dma_unmap_single' [-Wimplicit-function-declaration] dma_unmap_single(musb->controller, ^~~~ drivers/usb/musb-new/musb_gadget.c:139:7: error: 'DMA_TO_DEVICE' undeclared (first use in this function); did you mean 'USB_DT_DEVICE'? ? DMA_TO_DEVICE ^ USB_DT_DEVICE drivers/usb/musb-new/musb_gadget.c:140:7: error: 'DMA_FROM_DEVICE' undeclared (first use in this function); did you mean 'U_BOOT_DEVICE'? : DMA_FROM_DEVICE); ^~~ U_BOOT_DEVICE drivers/usb/musb-new/musb_gadget.c:143:3: warning: implicit declaration of function 'dma_sync_single_for_cpu' [-Wimplicit-function-declaration] dma_sync_single_for_cpu(musb->controller, ^~~ make[1]: *** [scripts/Makefile.build:279: drivers/usb/musb-new/musb_gadget.o] Error 1 ``` By diffing the resulting configuration, Othe main difference found is `CONFIG_USB_MUSB_PIO_ONLY` is not set when failing, and set to `=y` when working. This was verified to be the missing option. As far as I understand it in Kconfig, "is not set" basically marks the option as using a negative "unset" value, and does not mean that it will use the default value. This difference in meaning makes it so that when toggling the option with `make menuconfig`, the option has already been set to "is not set", and it does not change to its default value. The actual bug may be that there is a regression and the code should work when this value is unset, in this case I do not know how to provide the proper fix. This fix corrects the issue by gating the option behind `if USB_MUSB_HOST || USB_MUSB_GADGET`. To me, it looks like this was the intention, in the initial patch, but might have been overlooked. I assume so since the option was defined after the `if`, rather than before, like the other options not gated behind the option. drivers/usb/musb-new/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig index 79ad14ef66..d7754014e3 100644 --- a/drivers/usb/musb-new/Kconfig +++ b/drivers/usb/musb-new/Kconfig @@ -58,6 +58,7 @@ config USB_MUSB_PIC32 config USB_MUSB_SUNXI bool "Enable sunxi OTG / DRC USB controller" depends on ARCH_SUNXI + select USB_MUSB_PIO_ONLY default y ---help--- Say y here to enable support for the sunxi OTG / DRC USB controller -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ARM: imx6: DHCOM i.MX6 PDK: Fixing reset
Hello Claudius, On Thu, 2019-11-28 at 13:06 +0100, Claudius Heine wrote: > Hi, > > currently the reset on the DHCOM i.MX6 board is brocken in u-boot. > > This patchset fixes that by integrating the sysreset and watchdog dm driver. I think you should clarify that reset was broken by commit f2929d11a639 ("watchdog: imx: Use immediate reset bits for expire_now") which changed reset to, by default, only assert the external reset [1]. DHCOM i.MX6 needs the internal reset though, which previously was asserted as as well. Maybe you can add a `Fixes:` line to one of your commits? Additionally, I am still unsure whether the current default behavior is correct. I'd rather assert both external and internal reset, which is what the i.MX watchdog does on timeout as well (as long as WDT bit is set, which we do by default [2]). There is also an inconsistency between the non-DM implementation (external by default) and DM implementation (internal by default). > regards, > Claudius > > Claudius Heine (4): > ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver > ARM: imx6: DHCOM i.MX6 PDK: Enable sysreset driver > ARM: imx6: DHCOM i.MX6 PDK: Enable wdt command > ARM: imx6: DHCOM i.MX6 PDK: Use HW_WATCHDOG in SPL > > arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + > configs/dh_imx6_defconfig| 3 +++ > include/configs/dh_imx6.h| 5 + > 3 files changed, 13 insertions(+) > [1]: https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/watchdog/imx_watchdog.c#L45 [2]: https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/watchdog/imx_watchdog.c#L96 -- Harald ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: ftgmac100: align RX/TX descriptors on ARCH_DMA_MINALIGN
Fixes: e766849713ff ("net: ftgmac100: convert the RX/TX descriptor arrays") Signed-off-by: Cédric Le Goater --- drivers/net/ftgmac100.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c index 92c38a81bd35..c14647af7844 100644 --- a/drivers/net/ftgmac100.c +++ b/drivers/net/ftgmac100.c @@ -71,8 +71,8 @@ enum ftgmac100_model { struct ftgmac100_data { struct ftgmac100 *iobase; - struct ftgmac100_txdes txdes[PKTBUFSTX]; - struct ftgmac100_rxdes rxdes[PKTBUFSRX]; + struct ftgmac100_txdes txdes[PKTBUFSTX] __aligned(ARCH_DMA_MINALIGN); + struct ftgmac100_rxdes rxdes[PKTBUFSRX] __aligned(ARCH_DMA_MINALIGN); int tx_index; int rx_index; @@ -309,7 +309,7 @@ static int ftgmac100_start(struct udevice *dev) } priv->txdes[PKTBUFSTX - 1].txdes0 = priv->txdes0_edotr_mask; - start = (ulong)&priv->txdes[0]; + start = ((ulong)&priv->txdes[0]) & ~(ARCH_DMA_MINALIGN - 1); end = start + roundup(sizeof(priv->txdes), ARCH_DMA_MINALIGN); flush_dcache_range(start, end); @@ -319,7 +319,7 @@ static int ftgmac100_start(struct udevice *dev) } priv->rxdes[PKTBUFSRX - 1].rxdes0 = priv->rxdes0_edorr_mask; - start = (ulong)&priv->rxdes[0]; + start = ((ulong)&priv->rxdes[0]) & ~(ARCH_DMA_MINALIGN - 1); end = start + roundup(sizeof(priv->rxdes), ARCH_DMA_MINALIGN); flush_dcache_range(start, end); @@ -369,7 +369,7 @@ static int ftgmac100_free_pkt(struct udevice *dev, uchar *packet, int length) { struct ftgmac100_data *priv = dev_get_priv(dev); struct ftgmac100_rxdes *curr_des = &priv->rxdes[priv->rx_index]; - ulong des_start = (ulong)curr_des; + ulong des_start = ((ulong)curr_des) & ~(ARCH_DMA_MINALIGN - 1); ulong des_end = des_start + roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN); @@ -391,7 +391,7 @@ static int ftgmac100_recv(struct udevice *dev, int flags, uchar **packetp) struct ftgmac100_data *priv = dev_get_priv(dev); struct ftgmac100_rxdes *curr_des = &priv->rxdes[priv->rx_index]; unsigned short rxlen; - ulong des_start = (ulong)curr_des; + ulong des_start = ((ulong)curr_des) & ~(ARCH_DMA_MINALIGN - 1); ulong des_end = des_start + roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN); ulong data_start = curr_des->rxdes3; @@ -426,7 +426,7 @@ static int ftgmac100_recv(struct udevice *dev, int flags, uchar **packetp) static u32 ftgmac100_read_txdesc(const void *desc) { const struct ftgmac100_txdes *txdes = desc; - ulong des_start = (ulong)txdes; + ulong des_start = ((ulong)txdes) & ~(ARCH_DMA_MINALIGN - 1); ulong des_end = des_start + roundup(sizeof(*txdes), ARCH_DMA_MINALIGN); invalidate_dcache_range(des_start, des_end); @@ -444,7 +444,7 @@ static int ftgmac100_send(struct udevice *dev, void *packet, int length) struct ftgmac100_data *priv = dev_get_priv(dev); struct ftgmac100 *ftgmac100 = priv->iobase; struct ftgmac100_txdes *curr_des = &priv->txdes[priv->tx_index]; - ulong des_start = (ulong)curr_des; + ulong des_start = ((ulong)curr_des) & ~(ARCH_DMA_MINALIGN - 1); ulong des_end = des_start + roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN); ulong data_start; -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
On 28/11/2019 13.14, Marek Vasut wrote: > On 11/28/19 1:06 PM, Claudius Heine wrote: >> Signed-off-by: Claudius Heine >> --- >> arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> index af4719aaeb..572bcbf8f0 100644 >> --- a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> +++ b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> @@ -30,6 +30,11 @@ >> mux-int-port = <1>; >> mux-ext-port = <3>; >> }; >> + >> +wdt-reboot { >> +compatible = "wdt-reboot"; >> +wdt = <&wdog1>; >> +}; >> }; >> >> &audmux { > > This should go into separate -u-boot.dtsi , so the base DT can be easily > synced with Linux one. > Ok. Will do that in v2. Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Hi Claudius, On Thu, Nov 28, 2019 at 9:07 AM Claudius Heine wrote: > > Signed-off-by: Claudius Heine > --- > arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > index af4719aaeb..572bcbf8f0 100644 > --- a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > +++ b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > @@ -30,6 +30,11 @@ > mux-int-port = <1>; > mux-ext-port = <3>; > }; > + > + wdt-reboot { > + compatible = "wdt-reboot"; > + wdt = <&wdog1>; > + }; > }; Could you use the the same way that Linux handles the imx2_wdt? Please see the commit below: commit ceea0c145d0c38badfcfc5443138e94ab094dc4a Author: Robert Hancock Date: Tue Aug 6 11:05:29 2019 -0600 watchdog: imx: Add DT ext-reset handling The Linux imx2_wdt driver uses a fsl,ext-reset-output boolean in the device tree to specify whether the board design should use the external reset instead of the internal reset. Use this boolean to determine which mode to use rather than using external reset unconditionally. For the legacy non-DM mode, the external reset is always used in order to maintain the previous behavior. Signed-off-by: Robert Hancock ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ARM: imx6: DHCOM i.MX6 PDK: Fixing reset
Hi Harald, On 28/11/2019 13.34, Harald Seiler wrote: > Hello Claudius, > > On Thu, 2019-11-28 at 13:06 +0100, Claudius Heine wrote: >> Hi, >> >> currently the reset on the DHCOM i.MX6 board is brocken in u-boot. >> >> This patchset fixes that by integrating the sysreset and watchdog dm driver. > > I think you should clarify that reset was broken by commit f2929d11a639 > ("watchdog: imx: Use immediate reset bits for expire_now") which changed > reset to, by default, only assert the external reset [1]. DHCOM i.MX6 > needs the internal reset though, which previously was asserted as as > well. Maybe you can add a `Fixes:` line to one of your commits? Hmm... Not sure which of the commit should have the 'Fixes' line though, since each does some part of fixing it. Maybe I should squash them? > > Additionally, I am still unsure whether the current default behavior is > correct. I'd rather assert both external and internal reset, which is > what the i.MX watchdog does on timeout as well (as long as WDT bit is > set, which we do by default [2]). There is also an inconsistency > between the non-DM implementation (external by default) and DM > implementation (internal by default). Yes, but that is a separate discussion IMO. This patch just addresses the stuff for DHCOM does not touch the imx-watchdog driver. Maybe an RFC patch that fixes the inconsistency might be useful to start it. regards, Claudius ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Hello Claudius, Fabio, On Thu, 2019-11-28 at 09:49 -0300, Fabio Estevam wrote: > Hi Claudius, > > On Thu, Nov 28, 2019 at 9:07 AM Claudius Heine wrote: > > Signed-off-by: Claudius Heine > > --- > > arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > > b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > > index af4719aaeb..572bcbf8f0 100644 > > --- a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > > +++ b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi > > @@ -30,6 +30,11 @@ > > mux-int-port = <1>; > > mux-ext-port = <3>; > > }; > > + > > + wdt-reboot { > > + compatible = "wdt-reboot"; > > + wdt = <&wdog1>; > > + }; > > }; > > Could you use the the same way that Linux handles the imx2_wdt? > > Please see the commit below: > > commit ceea0c145d0c38badfcfc5443138e94ab094dc4a > Author: Robert Hancock > Date: Tue Aug 6 11:05:29 2019 -0600 > > watchdog: imx: Add DT ext-reset handling > > The Linux imx2_wdt driver uses a fsl,ext-reset-output boolean in the > device tree to specify whether the board design should use the external > reset instead of the internal reset. Use this boolean to determine which > mode to use rather than using external reset unconditionally. > > For the legacy non-DM mode, the external reset is always used in order > to maintain the previous behavior. I think the source of the problem lies within this: The old behavior (before commit f2929d11a639 ("watchdog: imx: Use immediate reset bits for expire_now")) was asserting *both* external and internal reset. The datasheet mentions the following for the bit to enable external reset: | There is no effect on [internal reset] upon writing on this bit. | [External reset] gets asserted along with [internal reset] if this bit | is set. If the intention was to keep the old behavior, the imx_watchdog_expire_now() function needs to be changed to either - (ext_reset == false) write WCR_WDE | WCR_WDA (ie. assert only internal), or - (ext_reset == true) write WCR_WDE (ie. assert both internal and external). -- Harald DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Hi Fabio, On 28/11/2019 13.49, Fabio Estevam wrote: > Hi Claudius, > > On Thu, Nov 28, 2019 at 9:07 AM Claudius Heine wrote: >> >> Signed-off-by: Claudius Heine >> --- >> arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> index af4719aaeb..572bcbf8f0 100644 >> --- a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> +++ b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi >> @@ -30,6 +30,11 @@ >> mux-int-port = <1>; >> mux-ext-port = <3>; >> }; >> + >> + wdt-reboot { >> + compatible = "wdt-reboot"; >> + wdt = <&wdog1>; >> + }; >> }; > > Could you use the the same way that Linux handles the imx2_wdt? That is the sysreset device node, not the imx2_wdt one. (I will move that into a '*-u-boot.dtsi' in v2) Or am I misunderstanding you? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Hi Claudius, On Thu, Nov 28, 2019 at 10:15 AM Claudius Heine wrote: > That is the sysreset device node, not the imx2_wdt one. (I will move > that into a '*-u-boot.dtsi' in v2) > > Or am I misunderstanding you? What I am asking is: why do we need a specific sysreset node for U-Boot? Can't we just add the wdog node the same way we do in the kernel (from the imx2_wdt binding) and get it to work? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
On 28/11/2019 14.18, Fabio Estevam wrote: > Hi Claudius, > > On Thu, Nov 28, 2019 at 10:15 AM Claudius Heine wrote: > >> That is the sysreset device node, not the imx2_wdt one. (I will move >> that into a '*-u-boot.dtsi' in v2) >> >> Or am I misunderstanding you? > > What I am asking is: why do we need a specific sysreset node for U-Boot? Good question. But I don't know a better answer to that than just saying that this is currently the way the reset is implemented in u-boot with DM AFAIK. > Can't we just add the wdog node the same way we do in the kernel (from > the imx2_wdt binding) and get it to work? Probably. But I currently don't know a way to do it that doesn't involve implementing new code. I am currently more or less just doing what others have done before for similar boards (display5). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/16] efi_loader: add secure boot support
On Tue, Nov 26, 2019 at 09:51:04AM +0900, AKASHI Takahiro wrote: > One of major missing features in current UEFI implementation is "secure boot." > The ultimate goal of my attempt is to implement image authentication based > on signature and provide UEFI secure boot support which would be fully > compliant with UEFI specification, section 32[1]. > (The code was originally developed by Patrick Wildt.) > > While this patch/RFC is still rough-edged, the aim here is to get early > feedbacks from the community as the patch is quite huge (in total) and also > as it's a security enhancement. > > Please note, however, this patch doesn't work on its own; there are > a couple of functional dependencies[2] and [3], that I have submitted > before. For complete workable patch set, see my repository[4], > which also contains exeperimental timestamp-based revocation suuport. > > My "non-volatile" support[5], which is under discussion, is not mandatory > and so not included here, but this inevitably implies that, for example, > signature database variables, like db and dbx, won't be persistent unless you > explicitly run "env save" command and that UEFI variables are not separated > from U-Boot environment. Anyhow, Linaro is also working on implementing > real "secure storage" solution based on TF-A and OP-TEE. > > > Supported features: > * image authentication based on db and dbx > * supported signature types are > EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images) > EFI_CERT_X509_GUID (x509 certificate for signed images) > * SecureBoot/SignatureSupport variables > * SetupMode and user mode > * variable authentication based on PK and KEK > EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS > * basic pytest test cases > > Unsupported features: (marked as TODO in most cases in the source code, > and won't be included in this series) > * hash algorithms other than SHA256 > * dbt: timestamp(RFC6131)-based certificate revocation > * dbr: OS recovery > * xxxDefault: default values for signature stores > * transition to AuditMode and DeployedMode > * recording rejected images in EFI_IMAGE_EXECUTION_INFO_TABLE > * verification "policy", in particular, check against signature's owner > * private authenticated variables > * variable authentication with EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS > * real secure storage support, including hardware-specific PK (Platform Key) > installation > > TODO's other than "Unsupported features": (won't be included in this series) > * struct efi_image_regions cannot have arbitrary number of regions > * fail recovery, in particular, in modifying authenticated variables > * support read-only attributes of well-defined global variables > in particular, "SignatureSupport" > * Extensive test suite (or more test cases) to confirm compatibility > with EDK2 > => I requested EDK SCT community to add tests[6]. > > Test: > * my pytest, included in this patch set, passed. > * efi_selftest passed. (At least no reguression.) > * Travis CI tests, except the following two, have passed: > - test/py sandbox > test/py/tests/test_fs/test_unlink.py test_unlink2 > - test/py sandbox with clang > cmd/efidebug.c:703:15: error: result of comparison of constant > 9223372036854775822 with expression of type 'int' is always false > [-Werror,-Wtautological-constant-out-of-range-compare] > But as you can see, those have nothing to do with my UEFI secure boot > patch and are existing bugs. > > Known issues: > * efitools is used in pytest, and its version must be v1.5.2 or later. > (Solution: You can define EFITOOLS_PATH in defs.py for your own efitools.) > * Pytest depends on standalone "helloworld" app for sandbox > (Solution: You can define HELLO_PATH in defs.py or Heinrich's [7].) > * Travis CI errors mentioned above > => I will send *separate* bug-fix patches once fixed. > > > Hints about how to use: > (Please see other documents, or my pytest scripts, for details.) > * You can create your own certificates with openssl. > * You can sign your application with sbsign (on Ubuntu). > * You can create raw data for signature database with efitools, and > install/manage authenticated variables with "env -set -e" command > or efitools' "UpdateVars.efi" application. > > > [1] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf > [2] https://lists.denx.de/pipermail/u-boot/2019-November/390127.html > (import x509/pkcs7 parsers from linux) > [3] https://lists.denx.de/pipermail/u-boot/2019-November/390150.html > (extend rsa_verify() for UEFI secure boot) > [4] http://git.linaro.org/people/takahiro.akashi/u-boot.git/ efi/secboot > [5] https://lists.denx.de/pipermail/u-boot/2019-September/382835.html > (non-volatile variables support) > [6] https://bugzilla.tianocore.org/show_bug.cgi?id=2230 > [7] https://lists.denx.de/pipermail/u-boot/2019-November/389593.html > > > Changes in v2 (Nov 26, 2019) > *
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
On Thu, Nov 28, 2019 at 10:42 AM Claudius Heine wrote: > > On 28/11/2019 14.18, Fabio Estevam wrote: > > Hi Claudius, > > > > On Thu, Nov 28, 2019 at 10:15 AM Claudius Heine wrote: > > > >> That is the sysreset device node, not the imx2_wdt one. (I will move > >> that into a '*-u-boot.dtsi' in v2) > >> > >> Or am I misunderstanding you? > > > > What I am asking is: why do we need a specific sysreset node for U-Boot? > > Good question. But I don't know a better answer to that than just saying > that this is currently the way the reset is implemented in u-boot with > DM AFAIK. > > > Can't we just add the wdog node the same way we do in the kernel (from > > the imx2_wdt binding) and get it to work? > > Probably. But I currently don't know a way to do it that doesn't involve > implementing new code. Could you please try passing the wdog node the same we do in the kernel? I prefer we have a single way to deal with watchdog instead of having a specific U-Boot method. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] mach-imx: bootaux: print stack pointer and reset vector
From: Igor Opaniuk 1. Change information printed about loaded M4 binary, print the stack pointer and reset vector addressed. 2. Add sanity check for the address provided as param. Signed-off-by: Igor Opaniuk --- arch/arm/mach-imx/imx_bootaux.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c index 3d9422d5a2..ee786f7d06 100644 --- a/arch/arm/mach-imx/imx_bootaux.c +++ b/arch/arm/mach-imx/imx_bootaux.c @@ -20,6 +20,9 @@ int arch_auxiliary_core_up(u32 core_id, ulong boot_private_data) stack = *(u32 *)boot_private_data; pc = *(u32 *)(boot_private_data + 4); + printf("## Starting auxiliary core stack = 0x%08lX, pc = 0x%08lX...\n", + stack, pc); + /* Set the stack and pc to M4 bootROM */ writel(stack, M4_BOOTROM_BASE_ADDR); writel(pc, M4_BOOTROM_BASE_ADDR + 4); @@ -80,7 +83,8 @@ static int do_bootaux(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) addr = simple_strtoul(argv[1], NULL, 16); - printf("## Starting auxiliary core at 0x%08lX ...\n", addr); + if (!addr) + return CMD_RET_FAILURE; ret = arch_auxiliary_core_up(0, addr); if (ret) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] mach-imx: bootaux: elf firmware support
From: Igor Opaniuk Currently imx-specific bootaux command doesn't support ELF format firmware for Cortex-M4 core. This patches introduces a PoC implementation of handling elf firmware (load_elf_image_phdr() was copy-pasted from elf.c just for PoC). This has the advantage that the user does not need to know to which address the binary has been linked to. However, in order to handle and load the elf sections to the right address, we need to translate the Cortex-M4 core memory addresses to primary/host CPU memory addresses (Cortex A7/A9 cores). This allows to boot firmwares from any location with just using bootaux, e.g.: > tftp ${loadaddr} hello_world.elf && bootaux ${loadaddr} Similar translation table can be found in the Linux remoteproc driver [1]. [1] https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/imx_rproc.c Signed-off-by: Igor Opaniuk Signed-off-by: Stefan Agner --- arch/arm/include/asm/mach-imx/sys_proto.h | 7 ++ arch/arm/mach-imx/imx_bootaux.c | 84 +-- arch/arm/mach-imx/mx7/soc.c | 28 3 files changed, 115 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h b/arch/arm/include/asm/mach-imx/sys_proto.h index 1e627c8fc3..ed5d9a1667 100644 --- a/arch/arm/include/asm/mach-imx/sys_proto.h +++ b/arch/arm/include/asm/mach-imx/sys_proto.h @@ -104,6 +104,13 @@ void gpr_init(void); #endif /* CONFIG_MX6 */ +/* address translation table */ +struct rproc_att { + u32 da; /* device address (From Cortex M4 view) */ + u32 sa; /* system bus address */ + u32 size; /* size of reg range */ +}; + u32 get_nr_cpus(void); u32 get_cpu_rev(void); u32 get_cpu_speed_grade_hz(void); diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c index c750cee60c..871169e771 100644 --- a/arch/arm/mach-imx/imx_bootaux.c +++ b/arch/arm/mach-imx/imx_bootaux.c @@ -7,18 +7,94 @@ #include #include #include +#include #include #include -int arch_auxiliary_core_up(u32 core_id, ulong boot_private_data) +const __weak struct rproc_att hostmap[] = { }; + +static const struct rproc_att *get_host_mapping(unsigned long auxcore) +{ + const struct rproc_att *mmap = hostmap; + + while (mmap && mmap->size) { + if (mmap->da <= auxcore && + mmap->da + mmap->size > auxcore) + return mmap; + mmap++; + } + + return NULL; +} + +/* + * A very simple elf loader, assumes the image is valid, returns the + * entry point address. + */ +static unsigned long load_elf_image_phdr(unsigned long addr) +{ + Elf32_Ehdr *ehdr; /* ELF header structure pointer */ + Elf32_Phdr *phdr; /* Program header structure pointer */ + int i; + + ehdr = (Elf32_Ehdr *)addr; + phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff); + + /* Load each program header */ + for (i = 0; i < ehdr->e_phnum; ++i, ++phdr) { + const struct rproc_att *mmap = get_host_mapping(phdr->p_paddr); + void *dst, *src; + + if (phdr->p_type != PT_LOAD) + continue; + + if (!mmap) { + printf("Invalid aux core address: %08x", + phdr->p_paddr); + return 0; + } + + dst = (void *)(phdr->p_paddr - mmap->da) + mmap->sa; + src = (void *)addr + phdr->p_offset; + + debug("Loading phdr %i to 0x%p (%i bytes)\n", + i, dst, phdr->p_filesz); + + if (phdr->p_filesz) + memcpy(dst, src, phdr->p_filesz); + if (phdr->p_filesz != phdr->p_memsz) + memset(dst + phdr->p_filesz, 0x00, + phdr->p_memsz - phdr->p_filesz); + flush_cache((unsigned long)dst & + ~(CONFIG_SYS_CACHELINE_SIZE - 1), + ALIGN(phdr->p_filesz, CONFIG_SYS_CACHELINE_SIZE)); + } + + return ehdr->e_entry; +} + +int arch_auxiliary_core_up(u32 core_id, ulong addr) { ulong stack, pc; - if (!boot_private_data) + if (!addr) return -EINVAL; - stack = *(u32 *)boot_private_data; - pc = *(u32 *)(boot_private_data + 4); + if (valid_elf_image(addr)) { + stack = 0x0; + pc = load_elf_image_phdr(addr); + if (!pc) + return CMD_RET_FAILURE; + + } else { + /* +* Assume binary file with vector table at the beginning. +* Cortex-M4 vector tables start with the stack pointer (SP) +* and reset vector (initial PC). +*/ + stack = *(u32 *)addr; + pc = *(u32 *)(addr + 4); + } printf("## Starting auxiliary core stack = 0x%08lX, pc = 0x%08lX...\n",
[U-Boot] [PATCH v2 2/3] mach-imx: bootaux: add dcache flushing before enabling M4
From: Igor Opaniuk This patch fixes the issue with broken bootaux command, when M4 binary is loaded and data cache isn't flushed before M4 core is enabled. Reproducing: > tftpboot ${loadaddr} ${board_name}/hello_world.bin > cp.b ${loadaddr} 0x7F8000 $filesize > bootaux 0x7F8000 Signed-off-by: Igor Opaniuk --- arch/arm/mach-imx/imx_bootaux.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c index ee786f7d06..c750cee60c 100644 --- a/arch/arm/mach-imx/imx_bootaux.c +++ b/arch/arm/mach-imx/imx_bootaux.c @@ -27,6 +27,8 @@ int arch_auxiliary_core_up(u32 core_id, ulong boot_private_data) writel(stack, M4_BOOTROM_BASE_ADDR); writel(pc, M4_BOOTROM_BASE_ADDR + 4); + flush_dcache_all(); + /* Enable M4 */ #ifdef CONFIG_IMX8M call_imx_sip(IMX_SIP_SRC, IMX_SIP_SRC_M4_START, 0, 0, 0); -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/16] efi_loader: add signature database parser
Akashi-san, On Tue, Nov 26, 2019 at 09:51:08AM +0900, AKASHI Takahiro wrote: > efi_signature_parse_sigdb() is a helper function will be used to parse > signature database variable and instantiate a signature store structure > in later patches. > > Signed-off-by: AKASHI Takahiro > --- > include/efi_loader.h | 3 + > lib/efi_loader/efi_signature.c | 227 + > 2 files changed, 230 insertions(+) > > diff --git a/include/efi_loader.h b/include/efi_loader.h > index 622bae6a6906..5297fb854905 100644 > --- a/include/efi_loader.h > +++ b/include/efi_loader.h > @@ -720,6 +720,9 @@ bool efi_signature_verify_with_sigdb(struct > efi_image_regions *regs, > efi_status_t efi_image_region_add(struct efi_image_regions *regs, > const void *start, const void *end, > int nocheck); > + > +void efi_sigstore_free(struct efi_signature_store *sigstore); > +struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name); > #endif /* CONFIG_EFI_SECURE_BOOT */ > > #else /* CONFIG_IS_ENABLED(EFI_LOADER) */ > diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c > index 87a39b790f67..9be13d5a4bbe 100644 > --- a/lib/efi_loader/efi_signature.c > +++ b/lib/efi_loader/efi_signature.c > @@ -581,4 +581,231 @@ efi_status_t efi_image_region_add(struct > efi_image_regions *regs, > > return EFI_SUCCESS; > } > + > +/** > + * efi_sigstore_free - free signature store > + * @sigstore:Pointer to signature store structure > + * > + * Feee all the memories held in signature store and itself, > + * which were allocated by efi_sigstore_parse_sigdb(). > + */ > +void efi_sigstore_free(struct efi_signature_store *sigstore) > +{ > + struct efi_signature_store *sigstore_next; > + struct efi_sig_data *sig_data, *sig_data_next; > + > + while (sigstore) { > + sigstore_next = sigstore->next; > + > + sig_data = sigstore->sig_data_list; > + while (sig_data) { > + if (sig_data) > + sig_data_next = sig_data->next; Why the extra if check? > + free(sig_data->data); > + free(sig_data); > + sig_data = sig_data_next; > + } > + > + free(sigstore); > + sigstore = sigstore_next; > + } > +} > + Thnaks /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] rockchip: px30: Fixup PMUGRF registers layout order
According to the PX30 TRM, the iomux registers come first, before the pull and strength control registers. Signed-off-by: Paul Kocialkowski Reviewed-by: Kever Yang Reviewed-by: Heiko Stuebner --- arch/arm/include/asm/arch-rockchip/grf_px30.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/grf_px30.h b/arch/arm/include/asm/arch-rockchip/grf_px30.h index c167bb42fac9..3d2a8770322e 100644 --- a/arch/arm/include/asm/arch-rockchip/grf_px30.h +++ b/arch/arm/include/asm/arch-rockchip/grf_px30.h @@ -112,18 +112,18 @@ struct px30_grf { check_member(px30_grf, mac_con1, 0x904); struct px30_pmugrf { - unsigned int gpio0a_e; - unsigned int gpio0b_e; - unsigned int gpio0c_e; - unsigned int gpio0d_e; - unsigned int gpio0a_p; - unsigned int gpio0b_p; - unsigned int gpio0c_p; - unsigned int gpio0d_p; unsigned int gpio0al_iomux; unsigned int gpio0bl_iomux; unsigned int gpio0cl_iomux; unsigned int gpio0dl_iomux; + unsigned int gpio0a_p; + unsigned int gpio0b_p; + unsigned int gpio0c_p; + unsigned int gpio0d_p; + unsigned int gpio0a_e; + unsigned int gpio0b_e; + unsigned int gpio0c_e; + unsigned int gpio0d_e; unsigned int gpio0l_sr; unsigned int gpio0h_sr; unsigned int gpio0l_smt; -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] rockchip: px30: Rename CONFIG_DEBUG_UART2_CHANNEL to CONFIG_DEBUG_UART_CHANNEL
UART3 also has two sets of pins that can be selected. Rename the config option to a common name, to allow it to be used for both UART2 and UART3. Signed-off-by: Paul Kocialkowski --- arch/arm/mach-rockchip/px30/Kconfig | 6 +++--- arch/arm/mach-rockchip/px30/px30.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-rockchip/px30/Kconfig b/arch/arm/mach-rockchip/px30/Kconfig index 109a37be15ad..9f3ad4f623b0 100644 --- a/arch/arm/mach-rockchip/px30/Kconfig +++ b/arch/arm/mach-rockchip/px30/Kconfig @@ -27,12 +27,12 @@ config TPL_MAX_SIZE config TPL_STACK default 0xff0e4fff -config DEBUG_UART2_CHANNEL - int "Mux channel to use for debug UART2" +config DEBUG_UART_CHANNEL + int "Mux channel to use for debug UART2/UART3" depends on DEBUG_UART_BOARD_INIT default 0 help - UART2 can use two different set of pins to route the output. + UART2 and UART3 can use two different set of pins to route the output. For using the UART for early debugging the route to use needs to be declared (0 or 1). diff --git a/arch/arm/mach-rockchip/px30/px30.c b/arch/arm/mach-rockchip/px30/px30.c index bacdcc0b938d..a2241cfc608d 100644 --- a/arch/arm/mach-rockchip/px30/px30.c +++ b/arch/arm/mach-rockchip/px30/px30.c @@ -222,7 +222,7 @@ void board_debug_uart_init(void) UART2_CLK_SEL_MASK, UART2_CLK_SEL_UART2 << UART2_CLK_SEL_SHIFT); -#if (CONFIG_DEBUG_UART2_CHANNEL == 1) +#if (CONFIG_DEBUG_UART_CHANNEL == 1) /* Enable early UART2 */ rk_clrsetreg(&grf->iofunc_con0, CON_IOMUX_UART2SEL_MASK, @@ -241,7 +241,7 @@ void board_debug_uart_init(void) GPIO1D3_MASK | GPIO1D2_MASK, GPIO1D3_UART2_RXM0 << GPIO1D3_SHIFT | GPIO1D2_UART2_TXM0 << GPIO1D2_SHIFT); -#endif /* CONFIG_DEBUG_UART2_CHANNEL == 1 */ +#endif /* CONFIG_DEBUG_UART_CHANNEL == 1 */ #endif /* CONFIG_DEBUG_UART_BASE && CONFIG_DEBUG_UART_BASE == ... */ } -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] rockchip: px30: Add support for using UART3 as debug UART
Some generic PX30 SoMs found in the wild use UART3 as their debug output instead of UART2 (used for MMC) and UART5. Make it possible to use UART3 as early debug output, with the associated clock and pinmux configuration. Two sets of output pins are supported (M0/M1). Future users should also note that the pinmux default in the dts is to use the M1 pins while the Kconfig option takes M0 as a default. Signed-off-by: Paul Kocialkowski Reviewed-by: Kever Yang Reviewed-by: Heiko Stuebner --- arch/arm/include/asm/arch-rockchip/cru_px30.h | 19 + arch/arm/mach-rockchip/px30/px30.c| 77 +++ 2 files changed, 96 insertions(+) diff --git a/arch/arm/include/asm/arch-rockchip/cru_px30.h b/arch/arm/include/asm/arch-rockchip/cru_px30.h index 7d9fd181aca2..798444ae49f5 100644 --- a/arch/arm/include/asm/arch-rockchip/cru_px30.h +++ b/arch/arm/include/asm/arch-rockchip/cru_px30.h @@ -357,6 +357,25 @@ enum { UART2_DIVNP5_SHIFT = 0, UART2_DIVNP5_MASK = 0x1f << UART2_DIVNP5_SHIFT, + /* CRU_CLK_SEL40_CON */ + UART3_PLL_SEL_SHIFT = 14, + UART3_PLL_SEL_MASK = 3 << UART3_PLL_SEL_SHIFT, + UART3_PLL_SEL_GPLL = 0, + UART3_PLL_SEL_24M, + UART3_PLL_SEL_480M, + UART3_PLL_SEL_NPLL, + UART3_DIV_CON_SHIFT = 0, + UART3_DIV_CON_MASK = 0x1f << UART3_DIV_CON_SHIFT, + + /* CRU_CLK_SEL41_CON */ + UART3_CLK_SEL_SHIFT = 14, + UART3_CLK_SEL_MASK = 3 << UART3_PLL_SEL_SHIFT, + UART3_CLK_SEL_UART3 = 0, + UART3_CLK_SEL_UART3_NP5, + UART3_CLK_SEL_UART3_FRAC, + UART3_DIVNP5_SHIFT = 0, + UART3_DIVNP5_MASK = 0x1f << UART3_DIVNP5_SHIFT, + /* CRU_CLK_SEL46_CON */ UART5_PLL_SEL_SHIFT = 14, UART5_PLL_SEL_MASK = 3 << UART5_PLL_SEL_SHIFT, diff --git a/arch/arm/mach-rockchip/px30/px30.c b/arch/arm/mach-rockchip/px30/px30.c index a2241cfc608d..5014ee83d748 100644 --- a/arch/arm/mach-rockchip/px30/px30.c +++ b/arch/arm/mach-rockchip/px30/px30.c @@ -37,6 +37,7 @@ static struct mm_region px30_mem_map[] = { struct mm_region *mem_map = px30_mem_map; #define PMU_PWRDN_CON 0xff18 +#define PMUGRF_BASE0xff01 #define GRF_BASE 0xff14 #define CRU_BASE 0xff2b #define VIDEO_PHY_BASE 0xff2e @@ -49,6 +50,23 @@ struct mm_region *mem_map = px30_mem_map; #define QOS_PRIORITY_LEVEL(h, l) h) & 3) << 8) | ((l) & 3)) +/* GRF_GPIO1BH_IOMUX */ +enum { + GPIO1B7_SHIFT = 12, + GPIO1B7_MASK= 0xf << GPIO1B7_SHIFT, + GPIO1B7_GPIO= 0, + GPIO1B7_FLASH_RDN, + GPIO1B7_UART3_RXM1, + GPIO1B7_SPI0_CLK, + + GPIO1B6_SHIFT = 8, + GPIO1B6_MASK= 0xf << GPIO1B6_SHIFT, + GPIO1B6_GPIO= 0, + GPIO1B6_FLASH_CS1, + GPIO1B6_UART3_TXM1, + GPIO1B6_SPI0_CSN, +}; + /* GRF_GPIO1CL_IOMUX */ enum { GPIO1C1_SHIFT = 4, @@ -128,6 +146,23 @@ enum { GPIO3A1_UART5_RX= 4, }; +/* PMUGRF_GPIO0CL_IOMUX */ +enum { + GPIO0C1_SHIFT = 2, + GPIO0C1_MASK= 0x3 << GPIO0C1_SHIFT, + GPIO0C1_GPIO= 0, + GPIO0C1_PWM_3, + GPIO0C1_UART3_RXM0, + GPIO0C1_PMU_DEBUG4, + + GPIO0C0_SHIFT = 0, + GPIO0C0_MASK= 0x3 << GPIO0C0_SHIFT, + GPIO0C0_GPIO= 0, + GPIO0C0_PWM_1, + GPIO0C0_UART3_TXM0, + GPIO0C0_PMU_DEBUG3, +}; + int arch_cpu_init(void) { static struct px30_grf * const grf = (void *)GRF_BASE; @@ -175,6 +210,11 @@ int arch_cpu_init(void) #ifdef CONFIG_DEBUG_UART_BOARD_INIT void board_debug_uart_init(void) { +#if defined(CONFIG_DEBUG_UART_BASE) && \ + (CONFIG_DEBUG_UART_BASE == 0xff168000) && \ + (CONFIG_DEBUG_UART_CHANNEL != 1) + static struct px30_pmugrf * const pmugrf = (void *)PMUGRF_BASE; +#endif static struct px30_grf * const grf = (void *)GRF_BASE; static struct px30_cru * const cru = (void *)CRU_BASE; @@ -191,6 +231,43 @@ void board_debug_uart_init(void) GPIO1C1_MASK | GPIO1C0_MASK, GPIO1C1_UART1_TX << GPIO1C1_SHIFT | GPIO1C0_UART1_RX << GPIO1C0_SHIFT); +#elif defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff168000) + /* GRF_IOFUNC_CON0 */ + enum { + CON_IOMUX_UART3SEL_SHIFT= 9, + CON_IOMUX_UART3SEL_MASK = 1 << CON_IOMUX_UART3SEL_SHIFT, + CON_IOMUX_UART3SEL_M0 = 0, + CON_IOMUX_UART3SEL_M1, + }; + + /* uart_sel_clk default select 24MHz */ + rk_clrsetreg(&cru->clksel_con[40], +UART3_PLL_SEL_MASK | UART3_DIV_CON_MASK, +UART3_PLL_SEL_24M << UART3_PLL_SEL_SHIFT | 0); + rk_clrsetreg(&cr
Re: [U-Boot] [PATCH v2 04/16] efi_loader: add signature database parser
On Thu, Nov 28, 2019 at 04:21:01PM +0200, Ilias Apalodimas wrote: > Akashi-san, > > On Tue, Nov 26, 2019 at 09:51:08AM +0900, AKASHI Takahiro wrote: > > efi_signature_parse_sigdb() is a helper function will be used to parse > > signature database variable and instantiate a signature store structure > > in later patches. > > > > Signed-off-by: AKASHI Takahiro > > --- > > include/efi_loader.h | 3 + > > lib/efi_loader/efi_signature.c | 227 + > > 2 files changed, 230 insertions(+) > > > > diff --git a/include/efi_loader.h b/include/efi_loader.h > > index 622bae6a6906..5297fb854905 100644 > > --- a/include/efi_loader.h > > +++ b/include/efi_loader.h > > @@ -720,6 +720,9 @@ bool efi_signature_verify_with_sigdb(struct > > efi_image_regions *regs, > > efi_status_t efi_image_region_add(struct efi_image_regions *regs, > > const void *start, const void *end, > > int nocheck); > > + > > +void efi_sigstore_free(struct efi_signature_store *sigstore); > > +struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name); > > #endif /* CONFIG_EFI_SECURE_BOOT */ > > > > #else /* CONFIG_IS_ENABLED(EFI_LOADER) */ > > diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c > > index 87a39b790f67..9be13d5a4bbe 100644 > > --- a/lib/efi_loader/efi_signature.c > > +++ b/lib/efi_loader/efi_signature.c > > @@ -581,4 +581,231 @@ efi_status_t efi_image_region_add(struct > > efi_image_regions *regs, > > > > return EFI_SUCCESS; > > } > > + > > +/** > > + * efi_sigstore_free - free signature store > > + * @sigstore: Pointer to signature store structure > > + * > > + * Feee all the memories held in signature store and itself, > > + * which were allocated by efi_sigstore_parse_sigdb(). > > + */ > > +void efi_sigstore_free(struct efi_signature_store *sigstore) > > +{ > > + struct efi_signature_store *sigstore_next; > > + struct efi_sig_data *sig_data, *sig_data_next; > > + > > + while (sigstore) { > > + sigstore_next = sigstore->next; > > + > > + sig_data = sigstore->sig_data_list; > > + while (sig_data) { > > + if (sig_data) > > + sig_data_next = sig_data->next; > > Why the extra if check? Looking at it again, maybe this is a typo and you wanted to check sig_data->next? > > > + free(sig_data->data); > > + free(sig_data); > > + sig_data = sig_data_next; > > + } > > + > > + free(sigstore); > > + sigstore = sigstore_next; > > + } > > +} > > + > > Thnaks > /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] board: colibri_imx7: reserve DDR memory for Cortex-M4
Hi Stefano, On Mon, Oct 14, 2019 at 3:40 PM wrote: > > > From: Igor Opaniuk > > i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for > > the rpmsg communication. Both use cases need a fixed location of > > memory reserved. For the rpmsg use case the reserved area needs > > to be in sync with the kernel's hardcoded vring descriptor location. > > Use the linux,usable-memory property to carve out 1MB of memory > > in case the M4 core is running. Also make sure that the i.MX 7 > > specific rpmsg driver does not get loaded in case we do not carve > > out memory. > > Signed-off-by: Stefan Agner > > Signed-off-by: Igor Opaniuk > > Signed-off-by: Igor Opaniuk > > Reviewed-by: Oleksandr Suvorov > > Applied to u-boot-imx, master, thanks ! Unfortunately I can't find this commit neither in u-boot-imx/next neither in u-boot-imx/master. > > Best regards, > Stefano Babic > > -- > = > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > = > -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] common: fdt_support: add support for setting usable memory
Hi Stefano, On Mon, Oct 14, 2019 at 3:40 PM wrote: > > > From: Igor Opaniuk > > Add support for setting linux,usable-memory property in the memory > > node of device tree for the kernel [1]. > > This property holds a base address and size, describing a > > limited region in which memory may be considered available for use by > > the kernel. Memory outside of this range is not available for use. > > [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt > > Signed-off-by: Igor Opaniuk > > Signed-off-by: Sanchayan Maity > > Signed-off-by: Stefan Agner > > Signed-off-by: Igor Opaniuk > > Reviewed-by: Oleksandr Suvorov > > Applied to u-boot-imx, master, thanks ! Unfortunately I can't find this commit neither in u-boot-imx/next neither in u-boot-imx/master. > > Best regards, > Stefano Babic > > -- > = > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > = > -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
On 28/11/2019 14.55, Fabio Estevam wrote: > On Thu, Nov 28, 2019 at 10:42 AM Claudius Heine wrote: >> >> On 28/11/2019 14.18, Fabio Estevam wrote: >>> Hi Claudius, >>> >>> On Thu, Nov 28, 2019 at 10:15 AM Claudius Heine wrote: >>> That is the sysreset device node, not the imx2_wdt one. (I will move that into a '*-u-boot.dtsi' in v2) Or am I misunderstanding you? >>> >>> What I am asking is: why do we need a specific sysreset node for U-Boot? >> >> Good question. But I don't know a better answer to that than just saying >> that this is currently the way the reset is implemented in u-boot with >> DM AFAIK. >> >>> Can't we just add the wdog node the same way we do in the kernel (from >>> the imx2_wdt binding) and get it to work? >> >> Probably. But I currently don't know a way to do it that doesn't involve >> implementing new code. > > Could you please try passing the wdog node the same we do in the kernel? > > I prefer we have a single way to deal with watchdog instead of having > a specific U-Boot method. Sorry, but we are probably misunderstanding each other here. So I try to go step by step to show how I think about this. Maybe that way we figure out where our understanding differs. Please bear with me, its a bit verbose :) My patch adds the 'wdt-reboot' device node which is needed by u-boot to reset the device but doesn't exist in the linux kernel (since there is no 'wdt-reboot' driver): + wdt-reboot { + compatible = "wdt-reboot"; + wdt = <&wdog1>; + }; This 'wdt-reboot' node instruments its driver (drivers/sysreset/sysreset_watchdog.c [1]) to use the watchdog node (arch/arm/dts/imx6qdl.dtsi [2]) and its driver (drivers/watchdog/imx_watchdog.c [3]). Neither the watchdog node in imx6qdl.dtsi [2], that is nearly identical to the one in the linux kernel [4], nor its driver [3] was touched by the changes in this patchset. The thing that has changed however is that 'CONFIG_SYSRESET_WATCHDOG' was enabled, which in turn enabled the 'CONFIG_WDT' switch. 'CONFIG_WDT' in turn disabled the 'hw_watchdog*' function definitions in the imx-watchdog driver and enabled 'CONFIG_WATCHDOG' and disabled 'CONFIG_HW_WATCHDOG'. The 'CONFIG_WATCHDOG' and 'CONFIG_HW_WATCHDOG' changes cause the 'WATCHDOG_RESET*' defines in [5] to no longer refer to the 'hw_watchdog*' but instead to the 'watchdog*' functions. Those functions are handled by the watchdog DM class driver [6]. [1] https://gitlab.denx.de/u-boot/u-boot/blob/4b19b89ca4a866b7baa642533e6dbd67cd832d27/drivers/sysreset/sysreset_watchdog.c#L48 [2] https://gitlab.denx.de/u-boot/u-boot/blob/4b19b89ca4a866b7baa642533e6dbd67cd832d27/arch/arm/dts/imx6qdl.dtsi#L659 [3] https://gitlab.denx.de/u-boot/u-boot/blob/4b19b89ca4a866b7baa642533e6dbd67cd832d27/drivers/watchdog/imx_watchdog.c [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl.dtsi?h=v5.4#n672 [5] https://gitlab.denx.de/u-boot/u-boot/blob/4b19b89ca4a866b7baa642533e6dbd67cd832d27/include/watchdog.h#L38 [6] https://gitlab.denx.de/u-boot/u-boot/blob/4b19b89ca4a866b7baa642533e6dbd67cd832d27/drivers/watchdog/wdt-uclass.c#L74 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Hi Claudius, On Thu, Nov 28, 2019 at 12:31 PM Claudius Heine wrote: > Sorry, but we are probably misunderstanding each other here. So I try to > go step by step to show how I think about this. Maybe that way we figure > out where our understanding differs. Please bear with me, its a bit > verbose :) What I don't understand is why do we need "wdt-reboot" for i.MX in U-Boot? The i.MX watchdog driver is capable of resetting via internal watchdog or via a WDOG_B pin when the fsl,ext-reset-output property is passed. > My patch adds the 'wdt-reboot' device node which is needed by u-boot to > reset the device but doesn't exist in the linux kernel (since there is Right. This is the point I don't understand: why do we need a U-Boot wdt-reboot implementation in the first place? The imx watchdog works in the kernel with DT. Why can't you just use the same binding in U-Boot? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Thu, Nov 28, 2019 at 1:23 AM Kever Yang wrote: > > Hi Vasily, > > I think this should not be needed, see comments below. Hi Kever, I've spent 2 weeks of my evenings debugging this issue but unfortunately I don't have a proper fix. This is the only solution that makes my rockpro64 reboot reliably with mainline u-boot and ATF. See my comments below. > Hi Philipp, Klaus and Christoph: > > Could you help to check why do you need below patch for your board? > > ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset > > > I think we don't need this workaround for rk3399 CPU_B voltage > supply, and > here is what I got: > - rockchip use cru glb_rst_1 for reboot in kernel; > - the glb_rst_1 will reset all the GPIO logic to default state; > - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which > may be > a pull up/down IO, > - the syr83x output with the hardware default state of the VSEL(with > RK3399 default IO output) >should be normal output(1.0V), and another state output for > suspend(disabled), > - In order to make the syr83x works as expected, the kernel setting of > syr83x should be correct, >check property: > fcs,suspend-voltage-selector = <1>; > This is correct for rockpro64(vsel connect to a gpio with default > pull down) on upstream, > but I don't have a puma schematic, so I don't know if this is > correct for puma. > - With correct setting in syr83x, the cpu_b should always have power > supply after reboot/reset with >cru glb_rst_1 reg. > So no workaround is needed in U-Boot, please correct me if anything is > missing. I already tried re-initializing SYR83x, see [1] (and thus fixed couple of the bugs in FAN53555 driver which has been broken since it was merged into u-boot) but it doesn't help with reboot issue on RockPro64. I checked VSEL gpio status and it's identical on cold boot and on soft reboot, so I doubt SYR83X settings are related since I checked regulators settings and they're correct. I tried to boot with CPUFREQ disabled - that didn't help, linux hangs when booted after soft reset. Also tried to boot with big cluster disabled - that didn't help either. So could you merge this patch please unless someone else wants to work on this issue? Thanks, Vasily. [1] https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751 > Thanks, > - Kever > On 2019/11/28 下午2:14, Vasily Khoruzhick wrote: > > Rockpro64 doesn't boot reliably after soft reset, so let's force power on > > reset by asserting sysreset pin if we detected soft reset. > > > > Signed-off-by: Vasily Khoruzhick > > --- > > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 > > configs/rockpro64-rk3399_defconfig| 1 + > > 2 files changed, 9 insertions(+) > > > > diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > > b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > > index 4648513ea9..bb94bcf7be 100644 > > --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > > +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > > @@ -6,11 +6,19 @@ > > #include "rk3399-u-boot.dtsi" > > #include "rk3399-sdram-lpddr4-100.dtsi" > > / { > > + config { > > + sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>; > > + }; > > + > > chosen { > > u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci; > > }; > > }; > > > > +&gpio1 { > > + u-boot,dm-pre-reloc; > > +}; > > + > > &vdd_center { > > regulator-min-microvolt = <95>; > > regulator-max-microvolt = <95>; > > diff --git a/configs/rockpro64-rk3399_defconfig > > b/configs/rockpro64-rk3399_defconfig > > index 49e27c91cb..d153ac5485 100644 > > --- a/configs/rockpro64-rk3399_defconfig > > +++ b/configs/rockpro64-rk3399_defconfig > > @@ -1,6 +1,7 @@ > > CONFIG_ARM=y > > CONFIG_ARCH_ROCKCHIP=y > > CONFIG_SYS_TEXT_BASE=0x0020 > > +CONFIG_SPL_GPIO_SUPPORT=y > > CONFIG_ROCKCHIP_RK3399=y > > CONFIG_ENV_OFFSET=0x3F8000 > > CONFIG_TARGET_ROCKPRO64_RK3399=y > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARC: enable unit tests on development platforms
Hi Alexey, ping! --- Eugeniy Paltsev From: Eugeniy Paltsev Sent: Friday, November 8, 2019 18:31 To: uboot-snps-...@synopsys.com; Alexey Brodkin Cc: u-boot@lists.denx.de; Eugeniy Paltsev Subject: [PATCH] ARC: enable unit tests on development platforms Enable unit tests on HSDK and AXS103 development platforms to run it in verification flow. Signed-off-by: Eugeniy Paltsev --- configs/axs103_defconfig | 2 ++ configs/hsdk_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/axs103_defconfig b/configs/axs103_defconfig index 8255d9fa068..73a224fa145 100644 --- a/configs/axs103_defconfig +++ b/configs/axs103_defconfig @@ -59,3 +59,5 @@ CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_STORAGE=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_UNIT_TEST=y +CONFIG_UT_TIME=y diff --git a/configs/hsdk_defconfig b/configs/hsdk_defconfig index e28ceae289c..c0b45513afd 100644 --- a/configs/hsdk_defconfig +++ b/configs/hsdk_defconfig @@ -63,3 +63,5 @@ CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_STORAGE=y CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_PANIC_HANG=y +CONFIG_UNIT_TEST=y +CONFIG_UT_TIME=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
On Thu, Nov 28, 2019 at 10:40:38AM +0100, Marek Vasut wrote: > On 11/28/19 7:22 AM, Heinrich Schuchardt wrote: > > On 11/26/19 6:07 PM, Marek Vasut wrote: > >> On 11/26/19 5:52 PM, Tom Rini wrote: > >>> On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote: > On 11/26/19 5:26 PM, Tom Rini wrote: > > On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote: > >> On 11/26/19 12:16 AM, Heinrich Schuchardt wrote: > >>> Dear maintainers, > >> > >> Hi, > >> > >>> we have been trying to move to the driver model for several years > >>> now. > >>> Starting in 2018 we have added warnings to the Makefile that > >>> boards not > >>> supporting the driver model will be eliminated. Still 24 % of the > >>> configuration files have not been converted and do not even use > >>> CONFIG_DM=y. > >>> > >>> If we want to get rid of legacy drivers, at some point we have to > >>> remove > >>> the 347 configuration files in the list below not using the > >>> driver model. > >>> > >>> I suggest to do this directly after the release of v2020.01 > >>> scheduled > >>> January 6th. > >>> > >>> This should not stop the maintainers from reinserting the boards > >>> after > >>> conversion to the driver model. > >> > >> Some boards just cannot accommodate this DM stuff. For those boards, > >> it's just bloat without any useful added value. Hence, these boards > >> would be removed because they cannot accommodate arbitrary bloat. > >> This > >> makes U-Boot not-so-universal bootloader anymore, but rather a > >> bloated one. > >> > >> I don't think we can force boards out or impose DM on everyone > >> unless we > >> can solve this bloat issue first. > > > > As someone who was involved in creating this DM stuff, do you have > > some > > ideas on addressing things? Given that you're responsible for a > > number > > of these platforms and can test out some ideas on them, what are you > > suggesting? > > How about directly calling driver functions for drivers which have > single instance only ? Then we could optimize out all the DM overhead > for that. > >>> > >>> And when are you hoping to post an RFC / example? > >> > >> Currently I have zero time available. Maybe someone else can look into > >> this option? > > > > Dear Marex, > > > > DM drivers make use of the DM infrastructure for instance for the > > allocation of the private data area. The uclass files often include > > common logic needed for accessing all drivers (see for example tpm_xfer()). > > > > So which drivers do you think of that could be simplified? > > UART for example ? You only usually have one. > > > I would also be interested to learn which of the 347 boards not using > > CONFIG_DM=y are still actively maintained. > > Probably quite a few of those iMX, omap and PPC ones. > The qemu ones are probably used for CI ? I need to reply more directly to the opening post but yes, i.MX is still for various reasons needing help, and no, shouldn't be dropped, but we need to have a serious conversation about it. The OMAP platforms probably could be dropped or need a quick conversion. PowerPC is another place where we need a serious conversation. MIPS I think just needs some updating for conversion, along with the vexpress ones we also use in CI via QEMU. -- 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/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Hi Robert, On Thu, Nov 28, 2019 at 1:22 PM Robert Hancock wrote: > I ended up needing to add this node for our board as well to be able to > reset from U-Boot using DM. The watchdog itself is set up just from its > own device tree entry, but there's nothing to tie the sysreset code into > using the watchdog (and which one to use, since iMX has two of them) > without that node being present. > > In Linux this works differently - the watchdog drivers that are capable > of triggering an immediate reset will register themselves as a reset > handler automatically so the system will try to use that functionality > in order to reboot the system. To avoid the need for that explicit > wdt-reboot node, something like this would need to be implemented in U-Boot. Thanks for the clarification! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] blk: Better guard some of our object files for linking
When we do not have CONFIG_BLK (or SPL/TPL) enabled there are very few cases where we need the blk_legacy code linked in. To catch these, build when we have CONFIG_PARTITIONS set. In addition, we only need cmd/blk_common.o to be linked in when we have CONFIG_HAVE_BLOCK_DEVICE set, so make use of that directly. Signed-off-by: Tom Rini --- cmd/Makefile | 2 +- cmd/blk_common.c | 2 -- drivers/block/Makefile | 2 +- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/cmd/Makefile b/cmd/Makefile index 2d723ea0f07d..f823d16755e6 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -15,7 +15,7 @@ obj-$(CONFIG_CMD_AES) += aes.o obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o obj-$(CONFIG_CMD_ADC) += adc.o obj-$(CONFIG_CMD_ARMFLASH) += armflash.o -obj-y += blk_common.o +obj-$(CONFIG_HAVE_BLOCK_DEVICE) += blk_common.o obj-$(CONFIG_CMD_SOURCE) += source.o obj-$(CONFIG_CMD_BCB) += bcb.o obj-$(CONFIG_CMD_BDI) += bdinfo.o diff --git a/cmd/blk_common.c b/cmd/blk_common.c index cee25a0d4100..c5514cf8f8e8 100644 --- a/cmd/blk_common.c +++ b/cmd/blk_common.c @@ -11,7 +11,6 @@ #include #include -#ifdef CONFIG_HAVE_BLOCK_DEVICE int blk_common_cmd(int argc, char * const argv[], enum if_type if_type, int *cur_devnump) { @@ -96,4 +95,3 @@ int blk_common_cmd(int argc, char * const argv[], enum if_type if_type, } } } -#endif diff --git a/drivers/block/Makefile b/drivers/block/Makefile index 3feb0aa997df..8443625091b7 100644 --- a/drivers/block/Makefile +++ b/drivers/block/Makefile @@ -6,7 +6,7 @@ obj-$(CONFIG_$(SPL_)BLK) += blk-uclass.o ifndef CONFIG_$(SPL_)BLK -obj-y += blk_legacy.o +obj-$(CONFIG_PARTITIONS) += blk_legacy.o endif ifndef CONFIG_SPL_BUILD -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ARM: imx6: DHCOM i.MX6 PDK: Fixing reset
On 2019-11-28 6:34 a.m., Harald Seiler wrote: > Hello Claudius, > > On Thu, 2019-11-28 at 13:06 +0100, Claudius Heine wrote: >> Hi, >> >> currently the reset on the DHCOM i.MX6 board is brocken in u-boot. >> >> This patchset fixes that by integrating the sysreset and watchdog dm driver. > > I think you should clarify that reset was broken by commit f2929d11a639 > ("watchdog: imx: Use immediate reset bits for expire_now") which changed > reset to, by default, only assert the external reset [1]. DHCOM i.MX6 > needs the internal reset though, which previously was asserted as as > well. Maybe you can add a `Fixes:` line to one of your commits? The behavior of the driver in the DM mode should match what the Linux IMX watchdog driver is doing for both the watchdog timeout and reset operations. The reset operation there explicitly uses either internal reset or external reset, not both. For the actual watchdog timeout, they both set the WDT bit or not depending on whether ext-reset is set, which it seems would result in either internal+external reset or just internal reset (it doesn't look like you can trigger only an external reset on timeout). > > Additionally, I am still unsure whether the current default behavior is > correct. I'd rather assert both external and internal reset, which is > what the i.MX watchdog does on timeout as well (as long as WDT bit is > set, which we do by default [2]). There is also an inconsistency > between the non-DM implementation (external by default) and DM > implementation (internal by default). The legacy non-DM implementation kept the settings for timeout the same as they were before. For the reset, it appears that it used to do internal+external reset whereas now it does external only, so it's possible that might cause an issue on some boards. However, they should really be switching to DM and setting the ext-reset attribute properly depending on which reset they actually want, as that's needed to get proper watchdog timeout/restart behavior in Linux as well. I doubt any board actually needs both internal and external resets since then Linux would be unable to reboot properly. > >> regards, >> Claudius >> >> Claudius Heine (4): >> ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver >> ARM: imx6: DHCOM i.MX6 PDK: Enable sysreset driver >> ARM: imx6: DHCOM i.MX6 PDK: Enable wdt command >> ARM: imx6: DHCOM i.MX6 PDK: Use HW_WATCHDOG in SPL >> >> arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi | 5 + >> configs/dh_imx6_defconfig| 3 +++ >> include/configs/dh_imx6.h| 5 + >> 3 files changed, 13 insertions(+) >> > > [1]: > https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/watchdog/imx_watchdog.c#L45 > [2]: > https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/watchdog/imx_watchdog.c#L96 > -- Robert Hancock Senior Software Developer SED Systems, a division of Calian Ltd. Email: hanc...@sedsystems.ca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
On 2019-11-28 9:43 a.m., Fabio Estevam wrote: > Hi Claudius, > > On Thu, Nov 28, 2019 at 12:31 PM Claudius Heine wrote: > >> Sorry, but we are probably misunderstanding each other here. So I try to >> go step by step to show how I think about this. Maybe that way we figure >> out where our understanding differs. Please bear with me, its a bit >> verbose :) > > What I don't understand is why do we need "wdt-reboot" for i.MX in U-Boot? > > The i.MX watchdog driver is capable of resetting via internal watchdog > or via a WDOG_B pin when the fsl,ext-reset-output property is passed. > >> My patch adds the 'wdt-reboot' device node which is needed by u-boot to >> reset the device but doesn't exist in the linux kernel (since there is > > Right. This is the point I don't understand: why do we need a U-Boot > wdt-reboot implementation in the first place? > > The imx watchdog works in the kernel with DT. Why can't you just use > the same binding in U-Boot? I ended up needing to add this node for our board as well to be able to reset from U-Boot using DM. The watchdog itself is set up just from its own device tree entry, but there's nothing to tie the sysreset code into using the watchdog (and which one to use, since iMX has two of them) without that node being present. In Linux this works differently - the watchdog drivers that are capable of triggering an immediate reset will register themselves as a reset handler automatically so the system will try to use that functionality in order to reboot the system. To avoid the need for that explicit wdt-reboot node, something like this would need to be implemented in U-Boot. > > Thanks > -- Robert Hancock Senior Software Developer SED Systems, a division of Calian Ltd. Email: hanc...@sedsystems.ca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
Hi Vasily, On 2019/11/28 下午11:51, Vasily Khoruzhick wrote: On Thu, Nov 28, 2019 at 1:23 AM Kever Yang wrote: Hi Vasily, I think this should not be needed, see comments below. Hi Kever, I've spent 2 weeks of my evenings debugging this issue but I can understand you work pretty hard on make it work, it's not so easy to identify the root cause some times, thanks very much for working on this. unfortunately I don't have a proper fix. This is the only solution that makes my rockpro64 reboot reliably with mainline u-boot and ATF. See my comments below. Hi Philipp, Klaus and Christoph: Could you help to check why do you need below patch for your board? ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset I think we don't need this workaround for rk3399 CPU_B voltage supply, and here is what I got: - rockchip use cru glb_rst_1 for reboot in kernel; - the glb_rst_1 will reset all the GPIO logic to default state; - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which may be a pull up/down IO, - the syr83x output with the hardware default state of the VSEL(with RK3399 default IO output) should be normal output(1.0V), and another state output for suspend(disabled), - In order to make the syr83x works as expected, the kernel setting of syr83x should be correct, check property: fcs,suspend-voltage-selector = <1>; This is correct for rockpro64(vsel connect to a gpio with default pull down) on upstream, but I don't have a puma schematic, so I don't know if this is correct for puma. - With correct setting in syr83x, the cpu_b should always have power supply after reboot/reset with cru glb_rst_1 reg. So no workaround is needed in U-Boot, please correct me if anything is missing. I already tried re-initializing SYR83x, see [1] (and thus fixed couple of the bugs in FAN53555 driver which has been broken since it was merged into u-boot) but it doesn't help with reboot issue on RockPro64. I checked VSEL gpio status and it's identical on cold boot and on soft reboot, so I doubt SYR83X settings are related since I checked regulators settings and they're correct. Could you help to provide some more info? - For code boot, syr83x VSEL is low, and what is its output voltage? - For reboot, syr83x VSEL is low, what is its output voltage? - For reboot, after this patch, the syr83x VSEL is high, what is its output voltage? I think the setting of syr83x is wrong if the output voltage is not the same for code boot and reboot. I tried to boot with CPUFREQ disabled - that didn't help, linux hangs when booted after soft reset. Also tried to boot with big cluster disabled - that didn't help either. This is strange, this patch only affects the big cluster CPU, if big cluster is disabled, then there is no reason this patch can work. Have you double check the big cluster is truly _DISABLED_? Thanks, - Kever So could you merge this patch please unless someone else wants to work on this issue? Thanks, Vasily. [1] https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751 Thanks, - Kever On 2019/11/28 下午2:14, Vasily Khoruzhick wrote: Rockpro64 doesn't boot reliably after soft reset, so let's force power on reset by asserting sysreset pin if we detected soft reset. Signed-off-by: Vasily Khoruzhick --- arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 configs/rockpro64-rk3399_defconfig| 1 + 2 files changed, 9 insertions(+) diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi index 4648513ea9..bb94bcf7be 100644 --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi @@ -6,11 +6,19 @@ #include "rk3399-u-boot.dtsi" #include "rk3399-sdram-lpddr4-100.dtsi" / { + config { + sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>; + }; + chosen { u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci; }; }; +&gpio1 { + u-boot,dm-pre-reloc; +}; + &vdd_center { regulator-min-microvolt = <95>; regulator-max-microvolt = <95>; diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig index 49e27c91cb..d153ac5485 100644 --- a/configs/rockpro64-rk3399_defconfig +++ b/configs/rockpro64-rk3399_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_GPIO_SUPPORT=y CONFIG_ROCKCHIP_RK3399=y CONFIG_ENV_OFFSET=0x3F8000 CONFIG_TARGET_ROCKPRO64_RK3399=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Thu, Nov 28, 2019 at 4:59 PM Kever Yang wrote: > > Hi Vasily, > > On 2019/11/28 下午11:51, Vasily Khoruzhick wrote: > > On Thu, Nov 28, 2019 at 1:23 AM Kever Yang > > wrote: > >> Hi Vasily, > >> > >> I think this should not be needed, see comments below. > > Hi Kever, > > > > I've spent 2 weeks of my evenings debugging this issue but > > I can understand you work pretty hard on make it work, it's not so easy > to identify the root cause > > some times, thanks very much for working on this. > > > unfortunately I don't have a proper fix. This is the only solution > > that makes my rockpro64 reboot reliably with mainline u-boot and ATF. > > See my comments below. > > > >> Hi Philipp, Klaus and Christoph: > >> > >> Could you help to check why do you need below patch for your board? > >> > >> ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on > >> reset > >> > >> > >> I think we don't need this workaround for rk3399 CPU_B voltage > >> supply, and > >> here is what I got: > >> - rockchip use cru glb_rst_1 for reboot in kernel; > >> - the glb_rst_1 will reset all the GPIO logic to default state; > >> - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which > >> may be > >> a pull up/down IO, > >> - the syr83x output with the hardware default state of the VSEL(with > >> RK3399 default IO output) > >> should be normal output(1.0V), and another state output for > >> suspend(disabled), > >> - In order to make the syr83x works as expected, the kernel setting of > >> syr83x should be correct, > >> check property: > >> fcs,suspend-voltage-selector = <1>; > >> This is correct for rockpro64(vsel connect to a gpio with default > >> pull down) on upstream, > >> but I don't have a puma schematic, so I don't know if this is > >> correct for puma. > >> - With correct setting in syr83x, the cpu_b should always have power > >> supply after reboot/reset with > >> cru glb_rst_1 reg. > >> So no workaround is needed in U-Boot, please correct me if anything is > >> missing. > > I already tried re-initializing SYR83x, see [1] (and thus fixed couple > > of the bugs in FAN53555 driver which has been broken since it was > > merged into u-boot) but it doesn't help with reboot issue on > > RockPro64. I checked VSEL gpio status and it's identical on cold boot > > and on soft reboot, so I doubt SYR83X settings are related since I > > checked regulators settings and they're correct. > > Could you help to provide some more info? > > - For code boot, syr83x VSEL is low, and what is its output voltage? > > - For reboot, syr83x VSEL is low, what is its output voltage? I'll double check later tonight. > - For reboot, after this patch, the syr83x VSEL is high, what is its > output voltage? This patch doesn't touch VSEL. It sets OTP_OUT to 1, see [1] "Over-Temperature Protection" and thus forces board reset. OTP_OUT is GPIO1 A6. VSEL (or rather CPU_B_SLEEP_H) is different pin, it's wired to GPIO1 C1 http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf > I think the setting of syr83x is wrong if the output voltage is not the > same for code boot and reboot. > > > > > I tried to boot with CPUFREQ disabled - that didn't help, linux hangs > > when booted after soft reset. > > > > Also tried to boot with big cluster disabled - that didn't help either. > > This is strange, this patch only affects the big cluster CPU, if big > cluster is disabled, then there is > > no reason this patch can work. Have you double check the big cluster is > truly _DISABLED_? See explanation above. > > Thanks, > > - Kever > > > > > So could you merge this patch please unless someone else wants to work > > on this issue? > > > > Thanks, > > Vasily. > > > > [1] > > https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751 > > > >> Thanks, > >> - Kever > >> On 2019/11/28 下午2:14, Vasily Khoruzhick wrote: > >>> Rockpro64 doesn't boot reliably after soft reset, so let's force power on > >>> reset by asserting sysreset pin if we detected soft reset. > >>> > >>> Signed-off-by: Vasily Khoruzhick > >>> --- > >>>arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 > >>>configs/rockpro64-rk3399_defconfig| 1 + > >>>2 files changed, 9 insertions(+) > >>> > >>> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > >>> b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > >>> index 4648513ea9..bb94bcf7be 100644 > >>> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > >>> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > >>> @@ -6,11 +6,19 @@ > >>>#include "rk3399-u-boot.dtsi" > >>>#include "rk3399-sdram-lpddr4-100.dtsi" > >>>/ { > >>> + config { > >>> + sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>; > >>> + }; > >>> + > >>>chosen { > >>>u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci; > >>>}; > >>>}; > >>> > >>> +&gpio1 { > >>> + u-boot,dm-pre-reloc; > >
Re: [U-Boot] [PATCH] net: ftgmac100: align RX/TX descriptors on ARCH_DMA_MINALIGN
On Thu, 28 Nov 2019 at 12:37, Cédric Le Goater wrote: > > Fixes: e766849713ff ("net: ftgmac100: convert the RX/TX descriptor arrays") > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley Thanks Cédric. This resolves the warnings I saw when running on a machine with the dcache enabled: CACHE: Misaligned operation at range [bd79d310, bd79d350] Cheers, Joel > --- > drivers/net/ftgmac100.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c > index 92c38a81bd35..c14647af7844 100644 > --- a/drivers/net/ftgmac100.c > +++ b/drivers/net/ftgmac100.c > @@ -71,8 +71,8 @@ enum ftgmac100_model { > struct ftgmac100_data { > struct ftgmac100 *iobase; > > - struct ftgmac100_txdes txdes[PKTBUFSTX]; > - struct ftgmac100_rxdes rxdes[PKTBUFSRX]; > + struct ftgmac100_txdes txdes[PKTBUFSTX] __aligned(ARCH_DMA_MINALIGN); > + struct ftgmac100_rxdes rxdes[PKTBUFSRX] __aligned(ARCH_DMA_MINALIGN); > int tx_index; > int rx_index; > > @@ -309,7 +309,7 @@ static int ftgmac100_start(struct udevice *dev) > } > priv->txdes[PKTBUFSTX - 1].txdes0 = priv->txdes0_edotr_mask; > > - start = (ulong)&priv->txdes[0]; > + start = ((ulong)&priv->txdes[0]) & ~(ARCH_DMA_MINALIGN - 1); > end = start + roundup(sizeof(priv->txdes), ARCH_DMA_MINALIGN); > flush_dcache_range(start, end); > > @@ -319,7 +319,7 @@ static int ftgmac100_start(struct udevice *dev) > } > priv->rxdes[PKTBUFSRX - 1].rxdes0 = priv->rxdes0_edorr_mask; > > - start = (ulong)&priv->rxdes[0]; > + start = ((ulong)&priv->rxdes[0]) & ~(ARCH_DMA_MINALIGN - 1); > end = start + roundup(sizeof(priv->rxdes), ARCH_DMA_MINALIGN); > flush_dcache_range(start, end); > > @@ -369,7 +369,7 @@ static int ftgmac100_free_pkt(struct udevice *dev, uchar > *packet, int length) > { > struct ftgmac100_data *priv = dev_get_priv(dev); > struct ftgmac100_rxdes *curr_des = &priv->rxdes[priv->rx_index]; > - ulong des_start = (ulong)curr_des; > + ulong des_start = ((ulong)curr_des) & ~(ARCH_DMA_MINALIGN - 1); > ulong des_end = des_start + > roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN); > > @@ -391,7 +391,7 @@ static int ftgmac100_recv(struct udevice *dev, int flags, > uchar **packetp) > struct ftgmac100_data *priv = dev_get_priv(dev); > struct ftgmac100_rxdes *curr_des = &priv->rxdes[priv->rx_index]; > unsigned short rxlen; > - ulong des_start = (ulong)curr_des; > + ulong des_start = ((ulong)curr_des) & ~(ARCH_DMA_MINALIGN - 1); > ulong des_end = des_start + > roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN); > ulong data_start = curr_des->rxdes3; > @@ -426,7 +426,7 @@ static int ftgmac100_recv(struct udevice *dev, int flags, > uchar **packetp) > static u32 ftgmac100_read_txdesc(const void *desc) > { > const struct ftgmac100_txdes *txdes = desc; > - ulong des_start = (ulong)txdes; > + ulong des_start = ((ulong)txdes) & ~(ARCH_DMA_MINALIGN - 1); > ulong des_end = des_start + roundup(sizeof(*txdes), > ARCH_DMA_MINALIGN); > > invalidate_dcache_range(des_start, des_end); > @@ -444,7 +444,7 @@ static int ftgmac100_send(struct udevice *dev, void > *packet, int length) > struct ftgmac100_data *priv = dev_get_priv(dev); > struct ftgmac100 *ftgmac100 = priv->iobase; > struct ftgmac100_txdes *curr_des = &priv->txdes[priv->tx_index]; > - ulong des_start = (ulong)curr_des; > + ulong des_start = ((ulong)curr_des) & ~(ARCH_DMA_MINALIGN - 1); > ulong des_end = des_start + > roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN); > ulong data_start; > -- > 2.21.0 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: Allow cache drivers to be used in SPL
On Thu, Nov 28, 2019 at 7:38 PM Simon Goldschmidt wrote: > > On Thu, Nov 28, 2019 at 1:59 AM Ley Foon Tan wrote: > > > > On Thu, Nov 28, 2019 at 4:33 AM Simon Goldschmidt > > wrote: > > > > > > Ley, Tom, > > > > > > Am 26.11.2019 um 10:26 schrieb Ley Foon Tan: > > > > On Fri, Nov 8, 2019 at 10:53 AM Ley Foon Tan > > > > wrote: > > > >> > > > >> Add an option for building cache drivers in SPL. > > > > > > Ley: > > > > > > What's the actual problem here? Can you further describe your change? > > > Why do you need to change drivers/cache/Makefile? That seems to only > > > make sense if you enable the new SPL_CACHE without (non-SPL) CACHE. > > > > > > However, the series this was pulled out from adds a new cache driver and > > > makes it select CACHE, not SPL_CACHE, so how would this be activated > > > anyway? > > > > > > Maybe it would be better to always dive down into drivers/cache/ if > > > CACHE is y? > > Hi Simon > > > > The existing drivers/cache is only build when compile for Uboot > > proper, but not SPL build. > > So, this patch mainly is to allow drivers/cache to compile in SPL build. > > User can enable CONFIG_SPL_CACHE if they need to include drivers/cache > > in SPL, eg: Agilex platform. > > But you might not have CACHE enabled since you can enable SPL_CACHE > without CACHE, see my suggestions below. > > > > > Regards > > Ley Foon > > > > > > > > Tom: > > > > > > As drivers/cache is rather new and initiated via the socfpga tree, would > > > you be OK for us to take this via the socfpga/next tree once it's sorted > > > out? > > > > > > Regards, > > > Simon > > > > > > >> > > > >> Signed-off-by: Ley Foon Tan > > > >> --- > > > >> common/spl/Kconfig | 5 + > > > >> drivers/Makefile | 1 + > > > >> drivers/cache/Makefile | 2 +- > > > >> 3 files changed, 7 insertions(+), 1 deletion(-) > > > >> > > > >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > >> index c661809923..6e095c33e1 100644 > > > >> --- a/common/spl/Kconfig > > > >> +++ b/common/spl/Kconfig > > > >> @@ -714,6 +714,11 @@ config SPL_UBI > > > >>README.ubispl for more info. > > > >> > > > >> if SPL_DM > > > >> +config SPL_CACHE > > > >> + bool "Support cache drivers in SPL" > > I think this needs to depend on CACHE. Okay. > > > > >> + help > > > >> + Enable support for cache drivers in SPL. > > > >> + > > > >> config SPL_DM_SPI > > > >> bool "Support SPI DM drivers in SPL" > > > >> help > > > >> diff --git a/drivers/Makefile b/drivers/Makefile > > > >> index 0befeddfcb..0e42d006b9 100644 > > > >> --- a/drivers/Makefile > > > >> +++ b/drivers/Makefile > > > >> @@ -31,6 +31,7 @@ ifndef CONFIG_TPL_BUILD > > > >> ifdef CONFIG_SPL_BUILD > > > >> > > > >> obj-$(CONFIG_SPL_BOOTCOUNT_LIMIT) += bootcount/ > > > >> +obj-$(CONFIG_SPL_CACHE) += cache/ > > Can you move this up to the common part and make it: Noted. > > obj-$(CONFIG_$(SPL_TPL_)CACHE) += cache/ > > > > >> obj-$(CONFIG_SPL_CPU_SUPPORT) += cpu/ > > > >> obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/ > > > >> obj-$(CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT) += ddr/fsl/ > > > >> diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile > > > >> index 4a6458c602..c1f766cfca 100644 > > > >> --- a/drivers/cache/Makefile > > > >> +++ b/drivers/cache/Makefile > > > >> @@ -1,5 +1,5 @@ > > > >> > > > >> -obj-$(CONFIG_CACHE) += cache-uclass.o > > > >> +obj-$(CONFIG_$(SPL_)CACHE) += cache-uclass.o > > This should then probably be $(SPL_TPL), too? > > Although we don't have CONFIG_TPL_CACHE, yet, it might be > better like that to prevent including cache drivers in TPL? Okay. Regards Ley Foon > > > > >> obj-$(CONFIG_SANDBOX) += sandbox_cache.o > > > >> obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o > > > >> obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o > > > >> -- > > > >> 2.19.0 > > > > Hi Tom > > > > > > > > Any comment on this patch? > > > > > > > > Regards > > > > > > > > Ley Foon > > > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] spl: Allow cache drivers to be used in SPL
Add an option for building cache drivers in SPL. Signed-off-by: Ley Foon Tan --- v2: - Added "depends on CACHE" to SPL_CACHE. - Change to use $(CONFIG_$(SPL_TPL_)CACHE) to enable cache DM build. --- common/spl/Kconfig | 6 ++ drivers/Makefile | 1 + drivers/cache/Makefile | 2 +- 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 1f122833a7..ce119d1cc6 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -714,6 +714,12 @@ config SPL_UBI README.ubispl for more info. if SPL_DM +config SPL_CACHE + depends on CACHE + bool "Support cache drivers in SPL" + help + Enable support for cache drivers in SPL. + config SPL_DM_SPI bool "Support SPI DM drivers in SPL" help diff --git a/drivers/Makefile b/drivers/Makefile index 0befeddfcb..aed591c614 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+ +obj-$(CONFIG_$(SPL_TPL_)CACHE) += cache/ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk/ obj-$(CONFIG_$(SPL_TPL_)DM) += core/ obj-$(CONFIG_$(SPL_TPL_)DFU) += dfu/ diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile index 4a6458c602..924217044a 100644 --- a/drivers/cache/Makefile +++ b/drivers/cache/Makefile @@ -1,5 +1,5 @@ -obj-$(CONFIG_CACHE) += cache-uclass.o +obj-$(CONFIG_$(SPL_TPL_)CACHE) += cache-uclass.o obj-$(CONFIG_SANDBOX) += sandbox_cache.o obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] spi: nxp_fspi: new driver for the FlexSPI controller
>-Original Message- >From: U-Boot On Behalf Of Michael Walle >Sent: Saturday, November 2, 2019 11:56 PM >To: u-boot@lists.denx.de >Subject: [U-Boot] [PATCH v2 1/2] spi: nxp_fspi: new driver for the FlexSPI >controller > >This is a port of the kernel's spi-nxp-fspi driver. It uses the new spi-mem >interface and does not expose the more generic spi-xfer interface. The source >was taken from the v5.3-rc3 tag. > >The port was straightforward: > - remove the interrupt handling and the completion by busy polling the > controller > - remove locks > - move the setup of the memory windows into claim_bus() > - move the setup of the speed into set_speed() > - port the device tree bindings from the original fspi_probe() to > ofdata_to_platdata() > >There were only some style change fixes, no change in any logic. For example, >there are busy loops where the return code is not handled correctly, eg. only >prints a warning with WARN_ON(). This port intentionally left most functions >unchanged to ease future bugfixes. > >This was tested on a custom LS1028A board. Because the LS1028A doesn't >have proper clock framework support, changing the clock speed was not >tested. This also means that it is not possible to change the SPI speed on >LS1028A for now (neither is it possible in the linux driver). > >Signed-off-by: Michael Walle >Reviewed-by: Jagan Teki >--- >changes since v1: > - fixed typo, thanks Jagan > > drivers/spi/Kconfig| 7 + > drivers/spi/Makefile | 1 + > drivers/spi/nxp_fspi.c | 997 + > 3 files changed, 1005 insertions(+) > create mode 100644 drivers/spi/nxp_fspi.c > >diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index >7be867d5b6..ad20309df8 100644 >--- a/drivers/spi/Kconfig >+++ b/drivers/spi/Kconfig >@@ -192,6 +192,13 @@ config MVEBU_A3700_SPI > used to access the SPI NOR flash on platforms embedding this > Marvell IP core. > >+config NXP_FSPI >+ bool "NXP FlexSPI driver" >+ depends on SPI_MEM >+ help >+Enable the NXP FlexSPI (FSPI) driver. This driver can be used to >+access the SPI NOR flash on platforms embedding this NXP IP core. >+ > config PIC32_SPI > bool "Microchip PIC32 SPI driver" > depends on MACH_PIC32 >diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index >ae4f2958f8..52462e19a3 100644 >--- a/drivers/spi/Makefile >+++ b/drivers/spi/Makefile >@@ -43,6 +43,7 @@ obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o > obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o > obj-$(CONFIG_MXC_SPI) += mxc_spi.o > obj-$(CONFIG_MXS_SPI) += mxs_spi.o >+obj-$(CONFIG_NXP_FSPI) += nxp_fspi.o > obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o > obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o > obj-$(CONFIG_PIC32_SPI) += pic32_spi.o >diff --git a/drivers/spi/nxp_fspi.c b/drivers/spi/nxp_fspi.c new file mode >100644 index 00..b808418eb6 >--- /dev/null >+++ b/drivers/spi/nxp_fspi.c >@@ -0,0 +1,997 @@ >+// SPDX-License-Identifier: GPL-2.0+ >+/* >+ * NXP FlexSPI(FSPI) controller driver. >+ * >+ * Copyright (c) 2019 Michael Walle The file is ported from Linux. Any particular reason of adding copyright? Can you change this to Author/Ported-by? >+ * >+ * This driver was originally ported from the linux kernel v5.4-rc3, >+which had >+ * the following notes: >+ * -priyankajain ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 079/101] x86: Add low-power subsystem (lpss) support
Hi Simon, On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote: > > This subsystem is present on various Intel SoCs. > > Add very basic support for taking an lpss device out of reset. > > Signed-off-by: Simon Glass > > --- > > Changes in v5: None > Changes in v4: > - Add support for updating power state > - Move this to intel_common > > Changes in v3: None > Changes in v2: None > > arch/x86/cpu/intel_common/Makefile | 1 + > arch/x86/cpu/intel_common/lpss.c | 44 ++ > arch/x86/include/asm/lpss.h| 36 > 3 files changed, 81 insertions(+) > create mode 100644 arch/x86/cpu/intel_common/lpss.c > create mode 100644 arch/x86/include/asm/lpss.h > > diff --git a/arch/x86/cpu/intel_common/Makefile > b/arch/x86/cpu/intel_common/Makefile > index 09212cee04..cc4e1c962b 100644 > --- a/arch/x86/cpu/intel_common/Makefile > +++ b/arch/x86/cpu/intel_common/Makefile > @@ -19,6 +19,7 @@ endif > obj-y += cpu.o > obj-y += fast_spi.o > obj-y += lpc.o > +obj-y += lpss.o > ifndef CONFIG_TARGET_EFI_APP > obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += microcode.o > ifndef CONFIG_$(SPL_)X86_64 > diff --git a/arch/x86/cpu/intel_common/lpss.c > b/arch/x86/cpu/intel_common/lpss.c > new file mode 100644 > index 00..26a2d2d1e3 > --- /dev/null > +++ b/arch/x86/cpu/intel_common/lpss.c > @@ -0,0 +1,44 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Special driver to handle of-platdata > + * > + * Copyright 2019 Google LLC > + * > + * Some code from coreboot lpss.c > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +enum { > + LPSS_RESET_CTL_REG = 0x204, > + > + /* > +* Bit 1:0 controls LPSS controller reset. > +* > +* 00 ->LPSS Host Controller is in reset (Reset Asserted) > +* 01/10 ->Reserved > +* 11 ->LPSS Host Controller is NOT at reset (Reset Released) > +*/ > + LPSS_CNT_RST_RELEASE= 3, > + > + /* Power management control and status register */ > + PME_CTRL_STATUS = 0x84, > + > + /* Bit 1:0 Powerstate, controls D0 and D3 state */ > + POWER_STATE_MASK= 3, Could we use #defines? These macros are register offsets and bit defines and should not be put in one enum. > +}; > + > +/* Take controller out of reset */ > +void lpss_reset_release(void *regs) > +{ > + writel(LPSS_CNT_RST_RELEASE, regs + LPSS_RESET_CTL_REG); > +} > + > +void lpss_set_power_state(struct udevice *dev, enum lpss_pwr_state state) > +{ > + dm_pci_clrset_config8(dev, PME_CTRL_STATUS, POWER_STATE_MASK, state); > +} > diff --git a/arch/x86/include/asm/lpss.h b/arch/x86/include/asm/lpss.h > new file mode 100644 > index 00..7814872688 > --- /dev/null > +++ b/arch/x86/include/asm/lpss.h > @@ -0,0 +1,36 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright 2019 Google LLC > + */ > + > +#ifndef __ASM_LPSS_H > +#define __ASM_LPSS_H > + > +struct udevice; > + > +/* D0 and D3 enable config */ > +enum lpss_pwr_state { > + STATE_D0 = 0, > + STATE_D3 = 3 > +}; > + > +/** > + * lpss_reset_release() - Release device from reset > + * > + * This is used for devices which have LPSS support. > + * > + * @regs: Pointer to device registers > + */ > +void lpss_reset_release(void *regs); > + > +/** > + * lpss_set_power_state() - Change power state of a device > + * > + * This is used for devices which have LPSS support. > + * > + * @dev: Device to update > + * @state: New power state to set > + */ > +void lpss_set_power_state(struct udevice *dev, enum lpss_pwr_state state); > + > +#endif > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
This entire patch series migrate freescale qspi driver to spi-mem framework. Patch 1 removes the old fsl qspi driver Patch 2 adds new qspi driver incorporating spi-mem framework which is ported version of linux qspi driver. Initial port was done by Frieder. Now, no more direct access to spi-nor memory is possible. Few changes were introduced to prevent uboot crash such as to add complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number instead of 1k. Immediate effect was observed on pfe while using 1k size as it access spi-nor memory directly. Using complete flash size resolves the crash but data read will not be valid. Patch 3 removes unused config options. Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header files. SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR. Patch 5 removes unused num-cs property for imx platforms Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR is no longer required and can be removed. Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files. While enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR at the same time. Patch 8 updates the device-tree properties treewide for layerscape boards by aligning it with linux device-tree properties. Frieder Schrempf (1): imx: imx6sx: Remove unused 'num-cs' property Kuldeep Singh (7): spi: Remove old freescale qspi driver spi: Transform the FSL QuadSPI driver to use the SPI MEM API treewide: Remove unused FSL QSPI config options configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig treewide: Update fsl qspi node dt properties as per spi-mem driver arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +- arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +- arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +- arch/arm/dts/fsl-ls1012a.dtsi |4 +- arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +- arch/arm/dts/fsl-ls1043a.dtsi |6 +- arch/arm/dts/fsl-ls1046a-frwy.dts |5 +- arch/arm/dts/fsl-ls1046a-qds.dtsi |5 +- arch/arm/dts/fsl-ls1046a-rdb.dts |5 +- arch/arm/dts/fsl-ls1046a.dtsi |4 +- arch/arm/dts/fsl-ls1088a-qds.dts |5 +- arch/arm/dts/fsl-ls1088a-rdb.dts |5 +- arch/arm/dts/fsl-ls1088a.dtsi |2 +- arch/arm/dts/fsl-ls2080a-qds.dts |5 +- arch/arm/dts/fsl-ls2080a.dtsi |4 +- arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |5 +- arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi |2 - arch/arm/dts/imx6sx-sdb-u-boot.dtsi |2 - arch/arm/dts/ls1021a-twr.dtsi |5 +- arch/arm/dts/ls1021a.dtsi |6 +- .../include/asm/arch-fsl-layerscape/config.h |1 - arch/arm/include/asm/arch-ls102xa/config.h|1 - configs/ls1012aqds_qspi_defconfig |2 +- configs/ls1012aqds_tfa_defconfig |2 +- configs/ls1012ardb_qspi_SECURE_BOOT_defconfig |2 +- configs/ls1012ardb_qspi_defconfig |2 +- configs/ls1012ardb_tfa_defconfig |2 +- configs/ls1043aqds_qspi_defconfig |2 +- configs/ls1043aqds_sdcard_qspi_defconfig |2 +- configs/ls1043aqds_tfa_SECURE_BOOT_defconfig |2 + configs/ls1043aqds_tfa_defconfig |2 +- configs/ls1046aqds_qspi_defconfig |2 +- configs/ls1046aqds_sdcard_qspi_defconfig |2 +- configs/ls1046aqds_tfa_SECURE_BOOT_defconfig |1 + configs/ls1046aqds_tfa_defconfig |2 +- configs/ls1046ardb_qspi_SECURE_BOOT_defconfig |2 +- configs/ls1046ardb_qspi_defconfig |2 +- configs/ls1046ardb_tfa_SECURE_BOOT_defconfig |2 +- configs/ls1046ardb_tfa_defconfig |2 +- drivers/spi/fsl_qspi.c| 1549 ++--- drivers/spi/fsl_qspi.h| 145 -- include/configs/ls1012a_common.h | 17 +- include/configs/ls1012afrwy.h |3 - include/configs/ls1012ardb.h |3 - include/configs/ls1021aiot.h |6 - include/configs/ls1021aqds.h | 11 - include/configs/ls1021atwr.h | 10 - include/configs/ls1043aqds.h | 10 - include/configs/ls1046afrwy.h |9 - include/configs/ls1046aqds.h | 19 - include/configs/ls1046ardb.h | 20 - include/configs/ls1088a_common.h |6 - include/configs/ls1088aqds.h |8 - include/configs/ls1088ardb.h | 18 - include/configs/ls2080aqds.h |2 - include/configs/ls2080ardb.h |8 +- include/configs/mx6sxsabreauto.h
[U-Boot] [PATCH 1/8] spi: Remove old freescale qspi driver
Remove freescale qspi driver which was based on spi-nor along with fsl_qspi.h as this is not used by new driver anymore Signed-off-by: Kuldeep Singh --- drivers/spi/fsl_qspi.c | 1170 drivers/spi/fsl_qspi.h | 145 - 2 files changed, 1315 deletions(-) delete mode 100644 drivers/spi/fsl_qspi.c delete mode 100644 drivers/spi/fsl_qspi.h diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c deleted file mode 100644 index 8e2a09df36..00 --- a/drivers/spi/fsl_qspi.c +++ /dev/null @@ -1,1170 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* - * Copyright 2013-2015 Freescale Semiconductor, Inc. - * - * Freescale Quad Serial Peripheral Interface (QSPI) driver - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include "fsl_qspi.h" - -DECLARE_GLOBAL_DATA_PTR; - -#define OFFSET_BITS_MASK GENMASK(23, 0) - -#define FLASH_STATUS_WEL 0x02 - -/* SEQID */ -#define SEQID_WREN 1 -#define SEQID_FAST_READ2 -#define SEQID_RDSR 3 -#define SEQID_SE 4 -#define SEQID_CHIP_ERASE 5 -#define SEQID_PP 6 -#define SEQID_RDID 7 -#define SEQID_BE_4K8 -#ifdef CONFIG_SPI_FLASH_BAR -#define SEQID_BRRD 9 -#define SEQID_BRWR 10 -#define SEQID_RDEAR11 -#define SEQID_WREAR12 -#endif -#define SEQID_WRAR 13 -#define SEQID_RDAR 14 - -/* QSPI CMD */ -#define QSPI_CMD_PP0x02/* Page program (up to 256 bytes) */ -#define QSPI_CMD_RDSR 0x05/* Read status register */ -#define QSPI_CMD_WREN 0x06/* Write enable */ -#define QSPI_CMD_FAST_READ 0x0b/* Read data bytes (high frequency) */ -#define QSPI_CMD_BE_4K 0x20/* 4K erase */ -#define QSPI_CMD_CHIP_ERASE0xc7/* Erase whole flash chip */ -#define QSPI_CMD_SE0xd8/* Sector erase (usually 64KiB) */ -#define QSPI_CMD_RDID 0x9f/* Read JEDEC ID */ - -/* Used for Micron, winbond and Macronix flashes */ -#defineQSPI_CMD_WREAR 0xc5/* EAR register write */ -#defineQSPI_CMD_RDEAR 0xc8/* EAR reigster read */ - -/* Used for Spansion flashes only. */ -#defineQSPI_CMD_BRRD 0x16/* Bank register read */ -#defineQSPI_CMD_BRWR 0x17/* Bank register write */ - -/* Used for Spansion S25FS-S family flash only. */ -#define QSPI_CMD_RDAR 0x65/* Read any device register */ -#define QSPI_CMD_WRAR 0x71/* Write any device register */ - -/* 4-byte address QSPI CMD - used on Spansion and some Macronix flashes */ -#define QSPI_CMD_FAST_READ_4B 0x0c/* Read data bytes (high frequency) */ -#define QSPI_CMD_PP_4B 0x12/* Page program (up to 256 bytes) */ -#define QSPI_CMD_SE_4B 0xdc/* Sector erase (usually 64KiB) */ - -/* fsl_qspi_platdata flags */ -#define QSPI_FLAG_REGMAP_ENDIAN_BIGBIT(0) - -/* default SCK frequency, unit: HZ */ -#define FSL_QSPI_DEFAULT_SCK_FREQ 5000 - -/* QSPI max chipselect signals number */ -#define FSL_QSPI_MAX_CHIPSELECT_NUM 4 - -/* Controller needs driver to swap endian */ -#define QUADSPI_QUIRK_SWAP_ENDIAN BIT(0) - -enum fsl_qspi_devtype { - FSL_QUADSPI_VYBRID, - FSL_QUADSPI_IMX6SX, - FSL_QUADSPI_IMX6UL_7D, - FSL_QUADSPI_IMX7ULP, -}; - -struct fsl_qspi_devtype_data { - enum fsl_qspi_devtype devtype; - u32 rxfifo; - u32 txfifo; - u32 ahb_buf_size; - u32 driver_data; -}; - -/** - * struct fsl_qspi_platdata - platform data for Freescale QSPI - * - * @flags: Flags for QSPI QSPI_FLAG_... - * @speed_hz: Default SCK frequency - * @reg_base: Base address of QSPI registers - * @amba_base: Base address of QSPI memory mapping - * @amba_total_size: size of QSPI memory mapping - * @flash_num: Number of active slave devices - * @num_chipselect: Number of QSPI chipselect signals - */ -struct fsl_qspi_platdata { - u32 flags; - u32 speed_hz; - fdt_addr_t reg_base; - fdt_addr_t amba_base; - fdt_size_t amba_total_size; - u32 flash_num; - u32 num_chipselect; -}; - -/** - * struct fsl_qspi_priv - private data for Freescale QSPI - * - * @flags: Flags for QSPI QSPI_FLAG_... - * @bus_clk: QSPI input clk frequency - * @speed_hz: Default SCK frequency - * @cur_seqid: current LUT table sequence id - * @sf_addr: flash access offset - * @amba_base: Base address of QSPI memory mapping of every CS - * @amba_total_size: size of QSPI memory mapping - * @cur_amba_base: Base address of QSPI memory mapping of current CS - * @flash_num: Number of active slave devices - * @num_chipselect: Number of QSPI chipselect signals - * @regs: Point to QSPI register structure for I/O access - */ -struct fsl_qspi_priv { - u32 flags; - u32 bus_clk; - u32 speed_hz; - u32 cur_seqid; -
[U-Boot] [PATCH 4/8] configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
Move CONFIG_FSL_QSPI to the boards defconfigs and while at it also move CONFIG_SPI_FLASH_SPANSION Signed-off-by: Frieder Schrempf Signed-off-by: Kuldeep Singh --- configs/ls1043aqds_qspi_defconfig| 2 +- configs/ls1043aqds_sdcard_qspi_defconfig | 2 +- configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 2 ++ configs/ls1043aqds_tfa_defconfig | 2 +- include/configs/ls1043aqds.h | 8 5 files changed, 5 insertions(+), 11 deletions(-) diff --git a/configs/ls1043aqds_qspi_defconfig b/configs/ls1043aqds_qspi_defconfig index 36e6f4cce4..31a5a8638d 100644 --- a/configs/ls1043aqds_qspi_defconfig +++ b/configs/ls1043aqds_qspi_defconfig @@ -39,7 +39,7 @@ CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_SPI_FLASH=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/configs/ls1043aqds_sdcard_qspi_defconfig b/configs/ls1043aqds_sdcard_qspi_defconfig index 3ee00a87eb..b29d886de8 100644 --- a/configs/ls1043aqds_sdcard_qspi_defconfig +++ b/configs/ls1043aqds_sdcard_qspi_defconfig @@ -52,7 +52,7 @@ CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_SPI_FLASH=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig index b3102ab6c1..02fa17d024 100644 --- a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig @@ -42,6 +42,7 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y CONFIG_SYS_FLASH_CFI=y CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_E1000=y CONFIG_FMAN_ENET=y @@ -53,6 +54,7 @@ CONFIG_DM_SCSI=y CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y +CONFIG_FSL_QSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1043aqds_tfa_defconfig b/configs/ls1043aqds_tfa_defconfig index e0e35e77af..74a745d39f 100644 --- a/configs/ls1043aqds_tfa_defconfig +++ b/configs/ls1043aqds_tfa_defconfig @@ -51,7 +51,7 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y CONFIG_SYS_FLASH_CFI=y CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h index 063e724b7c..fef5a2eb96 100644 --- a/include/configs/ls1043aqds.h +++ b/include/configs/ls1043aqds.h @@ -379,14 +379,6 @@ unsigned long get_board_ddr_clk(void); #define VDD_MV_MIN 819 #define VDD_MV_MAX 1212 -/* QSPI device */ -#if defined(CONFIG_TFABOOT) || \ - (defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)) -#ifdef CONFIG_FSL_QSPI -#define CONFIG_SPI_FLASH_SPANSION -#endif -#endif - /* * Miscellaneous configurable options */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/8] spi: Transform the FSL QuadSPI driver to use the SPI MEM API
To support the SPI MEM API, instead of modifying the existing U-Boot driver, this patch adds a port of the existing Linux driver. This also has the advantage that porting changes and fixes from Linux will be easier. Porting of driver left most of the functions unchanged while few of the changes are: - Enhance select_mem function to choose cs on which slave device is connected. - Specify complete flash size i.e memmap_size in any one of SFA1AD, SFA2AD, SFB1AD, SFB2AD based on cs number rather than filling 1k in all cs. This prevents uboot crash if SPI-NOR memory is accessed directly using absolute addresses. - Specify memmap_phy in SFAR register. Currently tested on LS1088ARDB, LS1012ARDB, LS1046ARDB, LS1046AFRWY, LS1043AQDS, LS1021ATWR, LS2080ARDB Signed-off-by: Frieder Schrempf Signed-off-by: Ashish Kumar Signed-off-by: Kuldeep Singh --- drivers/spi/fsl_qspi.c | 777 + 1 file changed, 777 insertions(+) create mode 100644 drivers/spi/fsl_qspi.c diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c new file mode 100644 index 00..788fa0416f --- /dev/null +++ b/drivers/spi/fsl_qspi.c @@ -0,0 +1,777 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/* + * Freescale QuadSPI driver. + * + * Copyright (C) 2013 Freescale Semiconductor, Inc. + * Copyright (C) 2018 Bootlin + * Copyright (C) 2018 exceet electronics GmbH + * Copyright (C) 2018 Kontron Electronics GmbH + * Copyright (C) 2019 NXP + * + * Based on the original fsl-quadspi.c spi-nor driver. + * Transition to spi-mem in spi-fsl-qspi.c + */ + +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +/* + * The driver only uses one single LUT entry, that is updated on + * each call of exec_op(). Index 0 is preset at boot with a basic + * read operation, so let's use the last entry (15). + */ +#defineSEQID_LUT 15 + +/* Registers used by the driver */ +#define QUADSPI_MCR0x00 +#define QUADSPI_MCR_RESERVED_MASK GENMASK(19, 16) +#define QUADSPI_MCR_MDIS_MASK BIT(14) +#define QUADSPI_MCR_CLR_TXF_MASK BIT(11) +#define QUADSPI_MCR_CLR_RXF_MASK BIT(10) +#define QUADSPI_MCR_DDR_EN_MASKBIT(7) +#define QUADSPI_MCR_END_CFG_MASK GENMASK(3, 2) +#define QUADSPI_MCR_SWRSTHD_MASK BIT(1) +#define QUADSPI_MCR_SWRSTSD_MASK BIT(0) + +#define QUADSPI_IPCR 0x08 +#define QUADSPI_IPCR_SEQID(x) ((x) << 24) + +#define QUADSPI_BUF3CR 0x1c +#define QUADSPI_BUF3CR_ALLMST_MASK BIT(31) +#define QUADSPI_BUF3CR_ADATSZ(x) ((x) << 8) +#define QUADSPI_BUF3CR_ADATSZ_MASK GENMASK(15, 8) + +#define QUADSPI_BFGENCR0x20 +#define QUADSPI_BFGENCR_SEQID(x) ((x) << 12) + +#define QUADSPI_BUF0IND0x30 +#define QUADSPI_BUF1IND0x34 +#define QUADSPI_BUF2IND0x38 +#define QUADSPI_SFAR 0x100 + +#define QUADSPI_SMPR 0x108 +#define QUADSPI_SMPR_DDRSMP_MASK GENMASK(18, 16) +#define QUADSPI_SMPR_FSDLY_MASKBIT(6) +#define QUADSPI_SMPR_FSPHS_MASKBIT(5) +#define QUADSPI_SMPR_HSENA_MASKBIT(0) + +#define QUADSPI_RBCT 0x110 +#define QUADSPI_RBCT_WMRK_MASK GENMASK(4, 0) +#define QUADSPI_RBCT_RXBRD_USEIPS BIT(8) + +#define QUADSPI_TBDR 0x154 + +#define QUADSPI_SR 0x15c +#define QUADSPI_SR_IP_ACC_MASK BIT(1) +#define QUADSPI_SR_AHB_ACC_MASKBIT(2) + +#define QUADSPI_FR 0x160 +#define QUADSPI_FR_TFF_MASKBIT(0) + +#define QUADSPI_SPTRCLR0x16c +#define QUADSPI_SPTRCLR_IPPTRC BIT(8) +#define QUADSPI_SPTRCLR_BFPTRC BIT(0) + +#define QUADSPI_SFA1AD 0x180 +#define QUADSPI_SFA2AD 0x184 +#define QUADSPI_SFB1AD 0x188 +#define QUADSPI_SFB2AD 0x18c +#define QUADSPI_RBDR(x)(0x200 + ((x) * 4)) + +#define QUADSPI_LUTKEY 0x300 +#define QUADSPI_LUTKEY_VALUE 0x5AF05AF0 + +#define QUADSPI_LCKCR 0x304 +#define QUADSPI_LCKER_LOCK BIT(0) +#define QUADSPI_LCKER_UNLOCK BIT(1) + +#define QUADSPI_RSER 0x164 +#define QUADSPI_RSER_TFIE BIT(0) + +#define QUADSPI_LUT_BASE 0x310 +#define QUADSPI_LUT_OFFSET (SEQID_LUT * 4 * 4) +#define QUADSPI_LUT_REG(idx) \ + (QUADSPI_LUT_BASE + QUADSPI_LUT_OFFSET + (idx) * 4) + +/* Instruction set for the LUT register */ +#define LUT_STOP 0 +#define LUT_CMD1 +#define LUT_ADDR 2 +#define LUT_DUMMY 3 +#define LUT_MODE 4 +#define LUT_MODE2 5 +#define LUT_MODE4 6 +#define LUT_FSL_READ
[U-Boot] [PATCH 7/8] configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
LS1046ARDB and LS1046AQDS have s25fs512s flashes. So let's enable CONFIG_SPI_FLASH_SPANSION in defconfigs Signed-off-by: Kuldeep Singh --- configs/ls1046aqds_qspi_defconfig | 2 +- configs/ls1046aqds_sdcard_qspi_defconfig | 2 +- configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1046aqds_tfa_defconfig | 2 +- configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 2 +- configs/ls1046ardb_qspi_defconfig | 2 +- configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 2 +- configs/ls1046ardb_tfa_defconfig | 2 +- include/configs/ls1046aqds.h | 8 include/configs/ls1046ardb.h | 7 --- 10 files changed, 8 insertions(+), 22 deletions(-) diff --git a/configs/ls1046aqds_qspi_defconfig b/configs/ls1046aqds_qspi_defconfig index 7339aba903..911b667601 100644 --- a/configs/ls1046aqds_qspi_defconfig +++ b/configs/ls1046aqds_qspi_defconfig @@ -37,7 +37,7 @@ CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_E1000=y diff --git a/configs/ls1046aqds_sdcard_qspi_defconfig b/configs/ls1046aqds_sdcard_qspi_defconfig index 88ed9b2aff..3fa95e5021 100644 --- a/configs/ls1046aqds_sdcard_qspi_defconfig +++ b/configs/ls1046aqds_sdcard_qspi_defconfig @@ -52,7 +52,7 @@ CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_E1000=y diff --git a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig index d4c6b549c0..91e768451f 100644 --- a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig @@ -41,6 +41,7 @@ CONFIG_FLASH_CFI_DRIVER=y CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y CONFIG_SYS_FLASH_CFI=y CONFIG_SF_DEFAULT_BUS=1 +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/configs/ls1046aqds_tfa_defconfig b/configs/ls1046aqds_tfa_defconfig index 3b6e561aa4..e3a753882a 100644 --- a/configs/ls1046aqds_tfa_defconfig +++ b/configs/ls1046aqds_tfa_defconfig @@ -50,7 +50,7 @@ CONFIG_FLASH_CFI_DRIVER=y CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y CONFIG_SYS_FLASH_CFI=y CONFIG_SF_DEFAULT_BUS=1 -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig index 92a4d506f6..cfc8bcdc91 100644 --- a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig @@ -31,7 +31,7 @@ CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y diff --git a/configs/ls1046ardb_qspi_defconfig b/configs/ls1046ardb_qspi_defconfig index 391b2d06db..1d574b9c95 100644 --- a/configs/ls1046ardb_qspi_defconfig +++ b/configs/ls1046ardb_qspi_defconfig @@ -34,7 +34,7 @@ CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y diff --git a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig index 534b0f6ac5..da76861ed6 100644 --- a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig @@ -31,7 +31,7 @@ CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index 265e1a0a7a..fd22304f4f 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -36,7 +36,7 @@ CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h index 437b6ac5e3..8d74f32c06 100644 --- a/include/configs/ls1046aqds.h +++ b/include/configs/ls1046aqds.h @@ -41,14 +41,6 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SPI_FLASH_EON /* cs2 */ #endif -/* QSPI */ -#if defined(CONFIG_TFABOOT) || \ - defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI) -#ifdef CONFIG_FSL_QSPI -#define CONFIG_SPI_FLASH_SPANSION -#endif -#endif - #ifdef CONFIG_SYS_DPAA_FMAN #define CONFIG_PHY_VITESSE #define CONFIG_PHY_REALTEK diff --git a/include/configs/ls1046ardb
[U-Boot] [PATCH 3/8] treewide: Remove unused FSL QSPI config options
Some of these options are not used by the driver anymore and some of them are obsolete as the information is gathered from the dt. Also consolidating defines in common headers. Signed-off-by: Frieder Schrempf Signed-off-by: Ashish Kumar Signed-off-by: Kuldeep Singh --- .../include/asm/arch-fsl-layerscape/config.h | 1 - arch/arm/include/asm/arch-ls102xa/config.h | 1 - include/configs/ls1012a_common.h | 17 + include/configs/ls1012afrwy.h | 3 --- include/configs/ls1012ardb.h | 3 --- include/configs/ls1021aiot.h | 6 -- include/configs/ls1021aqds.h | 11 --- include/configs/ls1021atwr.h | 10 -- include/configs/ls1043aqds.h | 2 -- include/configs/ls1046afrwy.h | 9 - include/configs/ls1046aqds.h | 11 --- include/configs/ls1046ardb.h | 13 - include/configs/ls1088a_common.h | 6 -- include/configs/ls1088aqds.h | 8 include/configs/ls1088ardb.h | 18 -- include/configs/ls2080aqds.h | 2 -- include/configs/ls2080ardb.h | 8 ++-- include/configs/mx6sxsabreauto.h | 6 -- include/configs/mx6sxsabresd.h | 11 --- include/configs/mx6ul_14x14_evk.h | 6 -- include/configs/mx6ullevk.h| 6 -- include/configs/mx7dsabresd.h | 8 include/configs/pcm052.h | 7 --- include/configs/vf610twr.h | 8 scripts/config_whitelist.txt | 5 - 25 files changed, 3 insertions(+), 183 deletions(-) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h b/arch/arm/include/asm/arch-fsl-layerscape/config.h index a83c70ece2..913f7b179f 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h @@ -304,7 +304,6 @@ #define CONFIG_SYS_FSL_ESDHC_BE #define CONFIG_SYS_FSL_WDOG_BE #define CONFIG_SYS_FSL_DSPI_BE -#define CONFIG_SYS_FSL_QSPI_BE #define CONFIG_SYS_FSL_CCSR_GUR_BE #define CONFIG_SYS_FSL_PEX_LUT_BE diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index 970537870d..3884948a2c 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -94,7 +94,6 @@ #define CONFIG_SYS_FSL_ESDHC_BE #define CONFIG_SYS_FSL_WDOG_BE #define CONFIG_SYS_FSL_DSPI_BE -#define CONFIG_SYS_FSL_QSPI_BE #define CONFIG_SYS_FSL_DCU_BE #define CONFIG_SYS_FSL_SEC_MON_LE #define CONFIG_SYS_FSL_SFP_VER_3_2 diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h index 2579e2fb37..efd0ee41b6 100644 --- a/include/configs/ls1012a_common.h +++ b/include/configs/ls1012a_common.h @@ -37,23 +37,8 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024) /*SPI device */ -#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT) #define CONFIG_SYS_FMAN_FW_ADDR0x400d -#define CONFIG_SPI_FLASH_SPANSION -#define CONFIG_FSL_SPI_INTERFACE -#define CONFIG_SF_DATAFLASH - -#define QSPI0_AMBA_BASE0x4000 -#define CONFIG_SPI_FLASH_SPANSION - -#define FSL_QSPI_FLASH_SIZESZ_64M -#define FSL_QSPI_FLASH_NUM 2 - -/* - * Environment - */ -#define CONFIG_ENV_OVERWRITE -#endif +#define CONFIG_SYS_FSL_QSPI_BASE 0x4000 /* SATA */ #define CONFIG_SCSI_AHCI_PLAT diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h index 44b37c5475..02d4351429 100644 --- a/include/configs/ls1012afrwy.h +++ b/include/configs/ls1012afrwy.h @@ -33,9 +33,6 @@ func(USB, usb, 0) #endif -#undef FSL_QSPI_FLASH_SIZE -#define FSL_QSPI_FLASH_SIZESZ_16M - /* MMC */ #ifdef CONFIG_MMC #define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33 diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h index 3cd7baf21d..c8d73a5c68 100644 --- a/include/configs/ls1012ardb.h +++ b/include/configs/ls1012ardb.h @@ -16,9 +16,6 @@ #define CONFIG_SYS_MEMTEST_START 0x8000 #define CONFIG_SYS_MEMTEST_END 0x9fff - -/* ENV */ -#define CONFIG_SYS_FSL_QSPI_BASE 0x4000 /* * I2C IO expander */ diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h index 0b2d331b9b..236a8d5f7c 100644 --- a/include/configs/ls1021aiot.h +++ b/include/configs/ls1021aiot.h @@ -131,12 +131,6 @@ /* SPI */ #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI) #define CONFIG_SPI_FLASH_SPANSION - -/* QSPI */ -#define QSPI0_AMBA_BASE0x4000 -#define FSL_QSPI_FLASH_SIZE(1 << 24) -#define FSL_QSPI_FLASH_NUM 2 -#define CONFIG_SPI_FLASH_SPANSION #endif /
[U-Boot] [PATCH 5/8] imx: imx6sx: Remove unused 'num-cs' property
From: Frieder Schrempf This property is not used by the driver anymore so let's remove it. Other dts still have 'num-cs' set, but they need a resync with the Linux kernel anyway, so let's only do the U-Boot-specific files for now. Signed-off-by: Frieder Schrempf Signed-off-by: Kuldeep Singh --- arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi | 2 -- arch/arm/dts/imx6sx-sdb-u-boot.dtsi | 2 -- 2 files changed, 4 deletions(-) diff --git a/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi b/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi index 549461df71..5200448a9d 100644 --- a/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi +++ b/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi @@ -4,8 +4,6 @@ */ &qspi1 { - num-cs = <2>; - flash0: n25q256a@0 { compatible = "jedec,spi-nor"; }; diff --git a/arch/arm/dts/imx6sx-sdb-u-boot.dtsi b/arch/arm/dts/imx6sx-sdb-u-boot.dtsi index 8f9236da0f..3c0fd874c1 100644 --- a/arch/arm/dts/imx6sx-sdb-u-boot.dtsi +++ b/arch/arm/dts/imx6sx-sdb-u-boot.dtsi @@ -4,8 +4,6 @@ */ &qspi2 { - num-cs = <2>; - flash0: n25q256a@0 { compatible = "jedec,spi-nor"; }; -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/8] configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig
Enable the config CONFIG_SPI_FLASH_SPANSION for ls1012ardb and ls1012aqds while disabling CONFIG_SPI_FLASH_BAR at the same time Signed-off-by: Ashish Kumar Signed-off-by: Kuldeep Singh --- configs/ls1012aqds_qspi_defconfig | 2 +- configs/ls1012aqds_tfa_defconfig | 2 +- configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 2 +- configs/ls1012ardb_qspi_defconfig | 2 +- configs/ls1012ardb_tfa_defconfig | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/configs/ls1012aqds_qspi_defconfig b/configs/ls1012aqds_qspi_defconfig index c73878af0a..3f0aafe8ca 100644 --- a/configs/ls1012aqds_qspi_defconfig +++ b/configs/ls1012aqds_qspi_defconfig @@ -55,7 +55,7 @@ CONFIG_DM_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=1000 -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_FSL_PFE=y CONFIG_DM_ETH=y diff --git a/configs/ls1012aqds_tfa_defconfig b/configs/ls1012aqds_tfa_defconfig index 99e3b65f51..0444a1372b 100644 --- a/configs/ls1012aqds_tfa_defconfig +++ b/configs/ls1012aqds_tfa_defconfig @@ -55,7 +55,7 @@ CONFIG_DM_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=1000 -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_FSL_PFE=y CONFIG_DM_ETH=y diff --git a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig index 3cb4e9585f..5bd6c3789d 100644 --- a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig @@ -37,7 +37,7 @@ CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_E1000=y CONFIG_PCI=y diff --git a/configs/ls1012ardb_qspi_defconfig b/configs/ls1012ardb_qspi_defconfig index 0b98d9ec38..ba47bf2f8d 100644 --- a/configs/ls1012ardb_qspi_defconfig +++ b/configs/ls1012ardb_qspi_defconfig @@ -39,7 +39,7 @@ CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_FSL_PFE=y CONFIG_DM_ETH=y diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index 4c57430c0a..694bb981cd 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -40,7 +40,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_HS200_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y -# CONFIG_SPI_FLASH_BAR is not set +CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_FSL_PFE=y CONFIG_DM_ETH=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 8/8] treewide: Update fsl qspi node dt properties as per spi-mem driver
According to new qspi driver, some properties like "bus-num, num-cs, big-endian" are no longer used. Device endiannes can be determined from device-type data in driver. Now use board specific compatibles, generic node names and specific labels to align with linux device-tree properties. Also consolidate spi-max-frequency to 50Mhz treewide. Signed-off-by: Kuldeep Singh --- arch/arm/dts/fsl-ls1012a-frdm.dtsi| 5 ++--- arch/arm/dts/fsl-ls1012a-qds.dtsi | 5 ++--- arch/arm/dts/fsl-ls1012a-rdb.dtsi | 5 ++--- arch/arm/dts/fsl-ls1012a.dtsi | 4 +--- arch/arm/dts/fsl-ls1043a-qds.dtsi | 5 ++--- arch/arm/dts/fsl-ls1043a.dtsi | 6 ++ arch/arm/dts/fsl-ls1046a-frwy.dts | 5 ++--- arch/arm/dts/fsl-ls1046a-qds.dtsi | 5 ++--- arch/arm/dts/fsl-ls1046a-rdb.dts | 5 ++--- arch/arm/dts/fsl-ls1046a.dtsi | 4 +--- arch/arm/dts/fsl-ls1088a-qds.dts | 5 ++--- arch/arm/dts/fsl-ls1088a-rdb.dts | 5 ++--- arch/arm/dts/fsl-ls1088a.dtsi | 2 +- arch/arm/dts/fsl-ls2080a-qds.dts | 5 ++--- arch/arm/dts/fsl-ls2080a.dtsi | 4 ++-- arch/arm/dts/fsl-ls2088a-rdb-qspi.dts | 5 ++--- arch/arm/dts/ls1021a-twr.dtsi | 5 ++--- arch/arm/dts/ls1021a.dtsi | 6 ++ 18 files changed, 33 insertions(+), 53 deletions(-) diff --git a/arch/arm/dts/fsl-ls1012a-frdm.dtsi b/arch/arm/dts/fsl-ls1012a-frdm.dtsi index a357793bfa..88aa24a6d2 100644 --- a/arch/arm/dts/fsl-ls1012a-frdm.dtsi +++ b/arch/arm/dts/fsl-ls1012a-frdm.dtsi @@ -15,14 +15,13 @@ }; &qspi { - bus-num = <0>; status = "okay"; - qflash0: s25fl128s@0 { + s25fs512s0: flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "jedec,spi-nor"; - spi-max-frequency = <2000>; + spi-max-frequency = <5000>; reg = <0>; }; }; diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi b/arch/arm/dts/fsl-ls1012a-qds.dtsi index a330597b6c..910d2a5c77 100644 --- a/arch/arm/dts/fsl-ls1012a-qds.dtsi +++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi @@ -43,14 +43,13 @@ }; &qspi { - bus-num = <0>; status = "okay"; - qflash0: s25fl128s@0 { + s25fs512s0: flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "jedec,spi-nor"; - spi-max-frequency = <2000>; + spi-max-frequency = <5000>; reg = <0>; }; }; diff --git a/arch/arm/dts/fsl-ls1012a-rdb.dtsi b/arch/arm/dts/fsl-ls1012a-rdb.dtsi index 55155fd321..3757051b78 100644 --- a/arch/arm/dts/fsl-ls1012a-rdb.dtsi +++ b/arch/arm/dts/fsl-ls1012a-rdb.dtsi @@ -19,14 +19,13 @@ }; &qspi { - bus-num = <0>; status = "okay"; - qflash0: s25fl128s@0 { + s25fs512s0: flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "jedec,spi-nor"; - spi-max-frequency = <2000>; + spi-max-frequency = <5000>; reg = <0>; }; }; diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi index 1125e5753b..2d70c82a72 100644 --- a/arch/arm/dts/fsl-ls1012a.dtsi +++ b/arch/arm/dts/fsl-ls1012a.dtsi @@ -107,14 +107,12 @@ }; qspi: quadspi@155 { - compatible = "fsl,vf610-qspi"; + compatible = "fsl,ls1021a-qspi"; #address-cells = <1>; #size-cells = <0>; reg = <0x0 0x155 0x0 0x1>, <0x0 0x4000 0x0 0x400>; reg-names = "QuadSPI", "QuadSPI-memory"; - num-cs = <1>; - big-endian; status = "disabled"; }; diff --git a/arch/arm/dts/fsl-ls1043a-qds.dtsi b/arch/arm/dts/fsl-ls1043a-qds.dtsi index 70e1a6a53f..884bdad196 100644 --- a/arch/arm/dts/fsl-ls1043a-qds.dtsi +++ b/arch/arm/dts/fsl-ls1043a-qds.dtsi @@ -53,14 +53,13 @@ }; &qspi { - bus-num = <0>; status = "okay"; - qflash0: s25fl128s@0 { + s25fl128s0: flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "jedec,spi-nor"; - spi-max-frequency = <2000>; + spi-max-frequency = <5000>; reg = <0>; }; }; diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi index b159c3ca73..1c1bd5092e 100644 --- a/arch/arm/dts/fsl-ls1043a.dtsi +++ b/arch/arm/dts/fsl-ls1043a.dtsi @@ -210,14 +210,12 @@ status = "disabled"; }; qspi: quadspi@155 { - compatible = "fsl,vf610-qspi"; + compatible = "fsl,ls1021a-qspi"; #address-cells = <1>;
Re: [U-Boot] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
>-Original Message- >From: U-Boot-Custodians On >Behalf Of Heinrich Schuchardt >Sent: Tuesday, November 26, 2019 4:46 AM >To: u-boot-custodi...@lists.denx.de; u-boot-board- >maintain...@lists.denx.de; U-Boot Mailing List >Subject: [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y > >Dear maintainers, > >we have been trying to move to the driver model for several years now. >Starting in 2018 we have added warnings to the Makefile that boards not >supporting the driver model will be eliminated. Still 24 % of the configuration >files have not been converted and do not even use CONFIG_DM=y. > >If we want to get rid of legacy drivers, at some point we have to remove the >347 configuration files in the list below not using the driver model. > >I suggest to do this directly after the release of v2020.01 scheduled January >6th. > >This should not stop the maintainers from reinserting the boards after >conversion to the driver model. > >Best regards > >Heinrich > >am3517_crane_defconfig >apf27_defconfig >apx4devkit_defconfig >aristainetos2b_defconfig >aristainetos2_defconfig >aristainetos_defconfig >aspenite_defconfig >at91rm9200ek_defconfig >at91rm9200ek_ram_defconfig >B4420QDS_defconfig >B4420QDS_NAND_defconfig >B4420QDS_SPIFLASH_defconfig >B4860QDS_defconfig >B4860QDS_NAND_defconfig >B4860QDS_SPIFLASH_defconfig >B4860QDS_SRIO_PCIE_BOOT_defconfig >bcm11130_defconfig >bcm11130_nand_defconfig >bcm23550_w1d_defconfig >bcm28155_ap_defconfig >bcm28155_w1d_defconfig >bcm911360_entphn_defconfig >bcm911360_entphn-ns_defconfig >bcm911360k_defconfig >bcm958300k_defconfig >bcm958300k-ns_defconfig >bcm958305k_defconfig >bcm958622hr_defconfig >bcm958712k_defconfig >bg0900_defconfig >BSC9131RDB_NAND_defconfig >BSC9131RDB_NAND_SYSCLK100_defconfig >BSC9131RDB_SPIFLASH_defconfig >BSC9131RDB_SPIFLASH_SYSCLK100_defconfig >BSC9132QDS_NAND_DDRCLK100_defconfig >BSC9132QDS_NAND_DDRCLK133_defconfig >BSC9132QDS_NOR_DDRCLK100_defconfig >BSC9132QDS_NOR_DDRCLK133_defconfig >BSC9132QDS_SDCARD_DDRCLK100_defconfig >BSC9132QDS_SDCARD_DDRCLK133_defconfig >BSC9132QDS_SPIFLASH_DDRCLK100_defconfig >BSC9132QDS_SPIFLASH_DDRCLK133_defconfig >C29XPCIE_defconfig >C29XPCIE_NAND_defconfig >C29XPCIE_SPIFLASH_defconfig >caddy2_defconfig >cm_t35_defconfig >cm_t54_defconfig >Cyrus_P5020_defconfig >Cyrus_P5040_defconfig >d2net_v2_defconfig >dms-ba16-1g_defconfig >dms-ba16_defconfig >dockstar_defconfig >duovero_defconfig >edb9315a_defconfig >edminiv2_defconfig >flea3_defconfig >gplugd_defconfig >highbank_defconfig >hrcon_defconfig >hrcon_dh_defconfig >ib62x0_defconfig >iconnect_defconfig >inetspace_v2_defconfig >kc1_defconfig >kmcoge4_defconfig >kmcoge5ne_defconfig >kmeter1_defconfig >kmopti2_defconfig >kmsupx5_defconfig >kmtegr1_defconfig >kmtepr2_defconfig >ls2080a_emu_defconfig >ls2080a_simu_defconfig >MigoR_defconfig >mpc8308_p1m_defconfig >MPC8308RDB_defconfig >MPC8313ERDB_33_defconfig >MPC8313ERDB_66_defconfig >MPC8313ERDB_NAND_33_defconfig >MPC8313ERDB_NAND_66_defconfig >MPC8315ERDB_defconfig >MPC8323ERDB_defconfig >MPC832XEMDS_ATM_defconfig >MPC832XEMDS_defconfig >MPC832XEMDS_HOST_33_defconfig >MPC832XEMDS_HOST_66_defconfig >MPC832XEMDS_SLAVE_defconfig >MPC8349EMDS_defconfig >MPC8349EMDS_PCI64_defconfig >MPC8349EMDS_SDRAM_defconfig >MPC8349EMDS_SLAVE_defconfig >MPC8349ITX_defconfig >MPC8349ITXGP_defconfig >MPC8349ITX_LOWBOOT_defconfig >MPC837XEMDS_defconfig >MPC837XEMDS_HOST_defconfig >MPC837XEMDS_SLAVE_defconfig >MPC837XERDB_defconfig >MPC837XERDB_SLAVE_defconfig >MPC8536DS_36BIT_defconfig >MPC8536DS_defconfig >MPC8536DS_SDCARD_defconfig >MPC8536DS_SPIFLASH_defconfig >MPC8541CDS_defconfig >MPC8541CDS_legacy_defconfig >MPC8544DS_defconfig >MPC8555CDS_defconfig >MPC8555CDS_legacy_defconfig >MPC8568MDS_defconfig >MPC8569MDS_ATM_defconfig >MPC8569MDS_defconfig >MPC8572DS_36BIT_defconfig >MPC8572DS_defconfig >MPC8610HPCD_defconfig >MPC8641HPCN_36BIT_defconfig >MPC8641HPCN_defconfig >mx23evk_defconfig >mx23_olinuxino_defconfig >mx25pdk_defconfig >mx28evk_auart_console_defconfig >mx28evk_defconfig >mx28evk_nand_defconfig >mx28evk_spi_defconfig >mx31pdk_defconfig >mx35pdk_defconfig >mx51evk_defconfig >mx53ard_defconfig >mx53evk_defconfig >mx53loco_defconfig >mx53smd_defconfig >mx6dlarm2_defconfig >mx6dlarm2_lpddr2_defconfig >mx6memcal_defconfig >mx6qarm2_defconfig >mx6qarm2_lpddr2_defconfig >net2big_v2_defconfig >netspace_lite_v2_defconfig >netspace_max_v2_defconfig >netspace_mini_v2_defconfig >netspace_v2_defconfig >nokia_rx51_defconfig >nsa310s_defconfig >omap3_ha_defconfig >omap4_panda_defconfig >omap4_sdp4430_defconfig >omap5_uevm_defconfig >openrd_base_defconfig >openrd_client_defconfig >openrd_ultimate_defconfig >P1010RDB-PA_36BIT_NAND_defconfig >P1010RDB-PA_36BIT_NOR_defconfig >P1010RDB-PA_36BIT_SDCARD_defconfig >P1010RDB-PA_36BIT_SPIFLASH_defconfig >P1010RDB-PA_NAND_defconfig >P1010RDB-PA_NOR_defconfig >P1010RDB-PA_SDCARD_defconfig >P1010RDB-PA_SPIFLASH_defconfig >P1010RDB-PB_36BIT_NAND_defconfig >P1010RDB-PB_36BIT_NOR_defcon
Re: [U-Boot] [PATCH v5 080/101] x86: Add a generic Intel pinctrl driver
Hi Simon, On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote: > > Recent Intel SoCs share a pinctrl mechanism with many common elements. Add > an implementation of this core functionality, allowing SoC-specific > drivers to avoid adding common code. > > As well as a pinctrl driver this provides a GPIO driver based on the same > code. > > Once other SoCs use this driver we may consider moving more properties to > the device tree (e.g. the community info and pad definitions). > > Signed-off-by: Simon Glass > --- > > Changes in v5: > - Add function to obtain ACPI gpio number > > Changes in v4: > - Add a binding file > - Split out GPIO code from the pinctrl driver > - Switch over to use pinctrl for pad init/config > > Changes in v3: None > Changes in v2: None > > arch/x86/include/asm/intel_pinctrl.h | 306 + > arch/x86/include/asm/intel_pinctrl_defs.h | 386 +++ > .../pinctrl/intel,apl-pinctrl.txt | 39 ++ > drivers/pinctrl/Kconfig | 9 + > drivers/pinctrl/Makefile | 1 + > drivers/pinctrl/intel/Kconfig | 7 + > drivers/pinctrl/intel/Makefile| 5 + > drivers/pinctrl/intel/pinctrl.c | 635 ++ > 8 files changed, 1388 insertions(+) > create mode 100644 arch/x86/include/asm/intel_pinctrl.h > create mode 100644 arch/x86/include/asm/intel_pinctrl_defs.h > create mode 100644 doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt > create mode 100644 drivers/pinctrl/intel/Kconfig > create mode 100644 drivers/pinctrl/intel/Makefile > create mode 100644 drivers/pinctrl/intel/pinctrl.c > > diff --git a/arch/x86/include/asm/intel_pinctrl.h > b/arch/x86/include/asm/intel_pinctrl.h > new file mode 100644 > index 00..72fd9246cb > --- /dev/null > +++ b/arch/x86/include/asm/intel_pinctrl.h > @@ -0,0 +1,306 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2017 Intel Corporation. > + * Copyright 2019 Google LLC > + * > + * Modified from coreboot gpio.h > + */ > + > +#ifndef __ASM_INTEL_PINCTRL_H > +#define __ASM_INTEL_PINCTRL_H Is this ApolloLake specific pinctrl, or Intel common? > + > +#include > + > +/** > + * struct pad_config - config for a pad > + * @pad: offset of pad within community > + * @pad_config: Pad config data corresponding to DW0, DW1, etc. > + */ > +struct pad_config { > + int pad; > + u32 pad_config[4]; > +}; > + > +#include > + > +/* GPIO community IOSF sideband clock gating */ > +#define MISCCFG_GPSIDEDPCGEN BIT(5) > +/* GPIO community RCOMP clock gating */ > +#define MISCCFG_GPRCOMPCDLCGEN BIT(4) > +/* GPIO community RTC clock gating */ > +#define MISCCFG_GPRTCDLCGENBIT(3) > +/* GFX controller clock gating */ > +#define MISCCFG_GSXSLCGEN BIT(2) > +/* GPIO community partition clock gating */ > +#define MISCCFG_GPDPCGEN BIT(1) > +/* GPIO community local clock gating */ > +#define MISCCFG_GPDLCGEN BIT(0) > +/* Enable GPIO community power management configuration */ > +#define MISCCFG_ENABLE_GPIO_PM_CONFIG (MISCCFG_GPSIDEDPCGEN | \ > + MISCCFG_GPRCOMPCDLCGEN | MISCCFG_GPRTCDLCGEN | MISCCFG_GSXSLCGEN \ > + | MISCCFG_GPDPCGEN | MISCCFG_GPDLCGEN) > + > +/* > + * GPIO numbers may not be contiguous and instead will have a different > + * starting pin number for each pad group. > + */ > +#define INTEL_GPP_BASE(first_of_community, start_of_group, end_of_group,\ > + group_pad_base) \ > + { \ > + .first_pad = (start_of_group) - (first_of_community), \ > + .size = (end_of_group) - (start_of_group) + 1, \ > + .acpi_pad_base = (group_pad_base), \ > + } > + > +/* > + * A pad base of -1 indicates that this group uses contiguous numbering > + * and a pad base should not be used for this group. > + */ > +#define PAD_BASE_NONE -1 > + > +/* The common/default group numbering is contiguous */ > +#define INTEL_GPP(first_of_community, start_of_group, end_of_group)\ > + INTEL_GPP_BASE(first_of_community, start_of_group, end_of_group,\ > + PAD_BASE_NONE) > + > +/** > + * struct reset_mapping - logical to actual value for PADRSTCFG in DW0 > + * > + * Note that the values are expected to be within the field placement of the > + * register itself. i.e. if the reset field is at 31:30 then the values > within > + * logical and chipset should occupy 31:30. > + */ > +struct reset_mapping { > + u32 logical; > + u32 chipset; > +}; > + > +/** > + * struct pad_group - describes the groups within each community > + * > + * @first_pad: offset of first pad of the group relative to the community > + * @size: size of the group > + * @acpi_pad_base: starting pin number for the pads in this group when they > are > + * used in ACPI. This is only needed if the pi
Re: [U-Boot] [PATCH] ARM: socfpga: Fix FPGA bitstream loading code
Hi, i think i have find the problem, but i think i doesn't have the experience for modifie that. on the file : drivers/fpga/ socfpga_gen5.c : line 161 : function : 1. we wait fot the return of the fonction with the value or 2. but he never comming its always the value then we are the timing out. Then the fpga is on configuration mode, my question is: 1. How to set him on user mode ? 2. Why the configuration is not finalised ? 3. Where i can find information for finalise it ? I want to contribute, but im a noobies :) Le jeu. 10 oct. 2019 à 09:48, Marek Vasut a écrit : > On 10/10/19 7:15 AM, Simon Goldschmidt wrote: > [...] > >>> Have you dropped this? It's assigned to me in patchwork (I'm going > >>> through the list of old items assigned to me...). > >> > >> I don't know, sorry. Apparently there isn't enough information to decide > >> whether this patch is correct or not. > >> > > > > Right. However, since it seems to work as is, I don't think we have a > real > > problem. > > I think the datasheet could use clarification in that aspect. But it > might be way too late for that. > > -- > Best regards, > Marek Vasut > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: dh-imx6: add wdt-reboot node for sysreset driver
Hi Fabio, On 28/11/2019 16.43, Fabio Estevam wrote: > Hi Claudius, > > On Thu, Nov 28, 2019 at 12:31 PM Claudius Heine wrote: > >> Sorry, but we are probably misunderstanding each other here. So I try to >> go step by step to show how I think about this. Maybe that way we figure >> out where our understanding differs. Please bear with me, its a bit >> verbose :) > > What I don't understand is why do we need "wdt-reboot" for i.MX in U-Boot? > > The i.MX watchdog driver is capable of resetting via internal watchdog > or via a WDOG_B pin when the fsl,ext-reset-output property is passed. Ok, right. Well my patches fixes the 'reset' command in u-boot and for that we need a sysreset driver in u-boot currently. The watchdog itself works fine IIRC. > >> My patch adds the 'wdt-reboot' device node which is needed by u-boot to >> reset the device but doesn't exist in the linux kernel (since there is > > Right. This is the point I don't understand: why do we need a U-Boot > wdt-reboot implementation in the first place? > > The imx watchdog works in the kernel with DT. Why can't you just use > the same binding in U-Boot? > > Thanks > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: at91: Print CPU serial number in cpuinfo
On 27.11.2019 14:44, Alexander Dahl wrote: > The SAMA5D2 and SAMA5D4 series SoCs have a 64-bit Serial Number (unique > ID) burned in, which is displayed with 'print_cpuinfo()' now (in the > same format the SAM-BA applet prints it). > > Example output: > > CPU: SAMA5D27 1G bits DDR2 SDRAM > Serial number 0: 0x4630394b >1: 0x190d2750 > Crystal frequency: 24 MHz > CPU clock: 492 MHz > Master clock : 164 MHz > > Signed-off-by: Alexander Dahl > --- > > I looked over lots of other 'print_cpuinfo()' implementations for > different SoCs and found none printing a unique ID at all. Is there > another place for this? Is it just few SoCs have such a serial number > at all? Or is it not desired to print those along with the other CPU > info? > Hi Alex, I do not have anything against it. Nor do I have a strong opinion about which way to go. Is it better to just have a CMD that prints out this serial or print it at boot ? Maybe some other people have a different idea ? Eugen > Greets > Alex > > --- > arch/arm/mach-at91/armv7/cpu.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/mach-at91/armv7/cpu.c b/arch/arm/mach-at91/armv7/cpu.c > index 5da067cda1..6d50e1aea4 100644 > --- a/arch/arm/mach-at91/armv7/cpu.c > +++ b/arch/arm/mach-at91/armv7/cpu.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > > #ifndef CONFIG_SYS_AT91_MAIN_CLOCK > @@ -42,9 +43,16 @@ void arch_preboot_os(void) > #if defined(CONFIG_DISPLAY_CPUINFO) > int print_cpuinfo(void) > { > + struct atmel_sfr *sfr = (struct atmel_sfr *)ATMEL_BASE_SFR; > char buf[32]; > > printf("CPU: %s\n", get_cpu_name()); > + > +#if defined(CONFIG_SAMA5D2) || defined(CONFIG_SAMA5D4) > + printf("Serial number 0: 0x%08x\n", sfr->sn0); > + printf(" 1: 0x%08x\n", sfr->sn1); > +#endif > + > printf("Crystal frequency: %8s MHz\n", > strmhz(buf, get_main_clk_rate())); > printf("CPU clock: %8s MHz\n", > -- > 2.20.1 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] spi: nxp_fspi: new driver for the FlexSPI controller
Am 2019-11-29 06:03, schrieb Priyanka Jain: -Original Message- From: U-Boot On Behalf Of Michael Walle Sent: Saturday, November 2, 2019 11:56 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH v2 1/2] spi: nxp_fspi: new driver for the FlexSPI controller This is a port of the kernel's spi-nxp-fspi driver. It uses the new spi-mem interface and does not expose the more generic spi-xfer interface. The source was taken from the v5.3-rc3 tag. The port was straightforward: - remove the interrupt handling and the completion by busy polling the controller - remove locks - move the setup of the memory windows into claim_bus() - move the setup of the speed into set_speed() - port the device tree bindings from the original fspi_probe() to ofdata_to_platdata() There were only some style change fixes, no change in any logic. For example, there are busy loops where the return code is not handled correctly, eg. only prints a warning with WARN_ON(). This port intentionally left most functions unchanged to ease future bugfixes. This was tested on a custom LS1028A board. Because the LS1028A doesn't have proper clock framework support, changing the clock speed was not tested. This also means that it is not possible to change the SPI speed on LS1028A for now (neither is it possible in the linux driver). Signed-off-by: Michael Walle Reviewed-by: Jagan Teki --- changes since v1: - fixed typo, thanks Jagan drivers/spi/Kconfig| 7 + drivers/spi/Makefile | 1 + drivers/spi/nxp_fspi.c | 997 + 3 files changed, 1005 insertions(+) create mode 100644 drivers/spi/nxp_fspi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 7be867d5b6..ad20309df8 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -192,6 +192,13 @@ config MVEBU_A3700_SPI used to access the SPI NOR flash on platforms embedding this Marvell IP core. +config NXP_FSPI + bool "NXP FlexSPI driver" + depends on SPI_MEM + help + Enable the NXP FlexSPI (FSPI) driver. This driver can be used to + access the SPI NOR flash on platforms embedding this NXP IP core. + config PIC32_SPI bool "Microchip PIC32 SPI driver" depends on MACH_PIC32 diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index ae4f2958f8..52462e19a3 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -43,6 +43,7 @@ obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o obj-$(CONFIG_MXC_SPI) += mxc_spi.o obj-$(CONFIG_MXS_SPI) += mxs_spi.o +obj-$(CONFIG_NXP_FSPI) += nxp_fspi.o obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o obj-$(CONFIG_PIC32_SPI) += pic32_spi.o diff --git a/drivers/spi/nxp_fspi.c b/drivers/spi/nxp_fspi.c new file mode 100644 index 00..b808418eb6 --- /dev/null +++ b/drivers/spi/nxp_fspi.c @@ -0,0 +1,997 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * NXP FlexSPI(FSPI) controller driver. + * + * Copyright (c) 2019 Michael Walle The file is ported from Linux. Any particular reason of adding copyright? so what? the "original" copyright is mentioned. It is certainly not the case that there wasn't any changes. I get the feeling that you just want to have "your" NXP copyright here. If any, there should be the copyright of the original spi-nxp-qspi.c driver, which is not NXP. But instead NXP - lets say borrowed - much of its code for "their" spi-nxp-fspi.c and _dropped_ all former copyrights. Can you change this to Author/Ported-by? Nope. -michael + * + * This driver was originally ported from the linux kernel v5.4-rc3, +which had + * the following notes: + * -priyankajain ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot