[PATCH 1/1] efi_loader: EFI_RNG_PROTOCOL
Do not use quotation marks for Kconfig help text. Replace rng abbreviation by full words. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index a7afa3f29e..84a4a35d80 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -127,7 +127,7 @@ config EFI_RNG_PROTOCOL bool "EFI_RNG_PROTOCOL support" depends on DM_RNG help - "Support for EFI_RNG_PROTOCOL implementation. Uses the rng - device on the platform" + Provide a EFI_RNG_PROTOCOL implementation using the hardware random + number generator of the platform. endif -- 2.25.0
Re: sandbox: CONFIG_SYS_RELOC_GD_ENV_ADDR?
On Fri, Feb 14, 2020 at 12:16:33PM -0700, Simon Glass wrote: > Hi AKASHI, > > On Thu, 13 Feb 2020 at 18:39, AKASHI Takahiro > wrote: > > > > Tom, Simon, > > > > Is CONFIG_SYS_RELOC_GD_ENV_ADDR really needed on sandbox? > > > > When I try to have a variable environment on emulated SPI flash, > > the U-Boot binary always crashes: (NOTE: assuming CONFIG_ENV_ADDR == 0) > > $ dd if=/dev/zero of=./spi.bin bs=1M count=4 > > $ u-boot -T > > U-Boot 2020.04-rc2-00015-gc9afef2b1938-dirty (Feb 14 2020 - 10:24:59 > > +0900) > > > > Model: sandbox > > DRAM: 128 MiB > > WDT: Started with servicing (60s timeout) > > MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD) > > Loading Environment from SPI Flash... SF: Detected m25p16 with page > > size 256 Bytes, erase size 64 KiB, total 2 MiB > > *** Warning - bad CRC, using default environment > > > > Segmentation fault (core dumped) > > > > If this configuration is disabled, panic doesn't happen. > > I think that it should be turned off in any sandbox*_defconfig. > > > > In addition, please update > > - doc/arch/sandbox.rst > > - doc/SPI/README.sandbox-spi > > Both two still mention already-removed command line option, --spi_sf. > > It is confusing. > > I'm not an expert on this, but I can't see any use for this in > sandbox. One problem might be that it should be using map_sysmem() > instead of a cast. If the option needs to be dropped for things to work, we should just drop it. When migrating some of the logic here in to CONFIG symbols I did match, I'm pretty certain, the previous behavior. But there's been a few other cases I got backwards, so this could have been another. So long as 'make tests' is happy after the change, we should just do it. -- Tom signature.asc Description: PGP signature
[PATCH v2] arm: dts: imx8mq-evk: add phy-reset-gpios for fec1
Instead of resetting the ethernet phy through functions in imx8mq_evk.c, let the
driver reset the phy via dts description adding a reset duration of 10 ms
following atheros 8031's datasheet recommendation.
Signed-off-by: Alifer Moraes
---
Changes since v1:
Improve commit log (Michael Trimarchi)
arch/arm/dts/imx8mq-evk.dts | 2 ++
board/freescale/imx8mq_evk/imx8mq_evk.c | 18 --
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/arch/arm/dts/imx8mq-evk.dts b/arch/arm/dts/imx8mq-evk.dts
index 3693933451..55294ba9c8 100644
--- a/arch/arm/dts/imx8mq-evk.dts
+++ b/arch/arm/dts/imx8mq-evk.dts
@@ -104,6 +104,8 @@
pinctrl-0 = <_fec1>;
phy-mode = "rgmii-id";
phy-handle = <>;
+ phy-reset-gpios = < 9 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
fsl,magic-packet;
status = "okay";
diff --git a/board/freescale/imx8mq_evk/imx8mq_evk.c
b/board/freescale/imx8mq_evk/imx8mq_evk.c
index cb39d0f2d6..b2f464abb1 100644
--- a/board/freescale/imx8mq_evk/imx8mq_evk.c
+++ b/board/freescale/imx8mq_evk/imx8mq_evk.c
@@ -64,29 +64,11 @@ int dram_init(void)
}
#ifdef CONFIG_FEC_MXC
-#define FEC_RST_PAD IMX_GPIO_NR(1, 9)
-static iomux_v3_cfg_t const fec1_rst_pads[] = {
- IMX8MQ_PAD_GPIO1_IO09__GPIO1_IO9 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-static void setup_iomux_fec(void)
-{
- imx_iomux_v3_setup_multiple_pads(fec1_rst_pads,
-ARRAY_SIZE(fec1_rst_pads));
-
- gpio_request(IMX_GPIO_NR(1, 9), "fec1_rst");
- gpio_direction_output(IMX_GPIO_NR(1, 9), 0);
- udelay(500);
- gpio_direction_output(IMX_GPIO_NR(1, 9), 1);
-}
-
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *gpr =
(struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
- setup_iomux_fec();
-
/* Use 125M anatop REF_CLK1 for ENET1, not from external */
clrsetbits_le32(>gpr[1], BIT(13) | BIT(17), 0);
return set_clk_enet(ENET_125MHZ);
--
2.17.1
Re: [PATCH 10/33] mtd: Rename free() to rfree()
Hi Simon, On Thu, 13 Feb 2020 at 02:06, Simon Goldschmidt wrote: > > On Wed, Feb 12, 2020 at 6:14 PM Simon Glass wrote: > > > > Hi Masahiro, > > > > On Wed, 12 Feb 2020 at 06:14, Masahiro Yamada wrote: > > > > > > On Mon, Jan 13, 2020 at 4:08 AM Simon Glass wrote: > > > > > > > > This function name conflicts with our desire to #define free() to > > > > something else on sandbox. Since it deals with resources, rename it to > > > > rfree(). > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > I noticed this commit was merged recently. > > > > > > Now 'free' is a reserved keyword > > > you cannot use in U-Boot. > > > > > > > > > Commit cc92c3c thru cf23c7c are horrible. > > > > > > > > > Commit cfda60f should have used > > > 'static inline' instead of #define. > > > > > > I cannot believe it. > > > > Are you sure you understand the problem I was trying to solve? I am > > using dlmalloc's existing means of adding a prefix, but I'm sure we > > could change it to another way. > > > > If we define malloc() as dlmalloc() in dlmalloc.c, then we could add a > > declaration in dlmalloc.h that uses static inline to convert calls to > > malloc() to call dlmalloc(). Then anything that doesn't include > > malloc.h would still call the C library malloc(). Is that what you are > > thinking? > > There is no "malloc()" in dlmalloc.c. It is called "mALLOc()" and by defining > USE_DL_PREFIX, you already have converted that to be linked as "dlmalloc()". > > I think there should be no difference in who calls what when converting your > defines to static inline functions. > > And yes, I also dislike the other patches that remove all occurrences of > 'free'. I think without knowing the backgrounds of your patches, that just > looks strange. OK I think that will work. I was trying to use what is there already, but it is a bit ugly. Regards, Simon
Re: sandbox: CONFIG_SYS_RELOC_GD_ENV_ADDR?
Hi AKASHI, On Thu, 13 Feb 2020 at 18:39, AKASHI Takahiro wrote: > > Tom, Simon, > > Is CONFIG_SYS_RELOC_GD_ENV_ADDR really needed on sandbox? > > When I try to have a variable environment on emulated SPI flash, > the U-Boot binary always crashes: (NOTE: assuming CONFIG_ENV_ADDR == 0) > $ dd if=/dev/zero of=./spi.bin bs=1M count=4 > $ u-boot -T > U-Boot 2020.04-rc2-00015-gc9afef2b1938-dirty (Feb 14 2020 - 10:24:59 > +0900) > > Model: sandbox > DRAM: 128 MiB > WDT: Started with servicing (60s timeout) > MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD) > Loading Environment from SPI Flash... SF: Detected m25p16 with page size > 256 Bytes, erase size 64 KiB, total 2 MiB > *** Warning - bad CRC, using default environment > > Segmentation fault (core dumped) > > If this configuration is disabled, panic doesn't happen. > I think that it should be turned off in any sandbox*_defconfig. > > In addition, please update > - doc/arch/sandbox.rst > - doc/SPI/README.sandbox-spi > Both two still mention already-removed command line option, --spi_sf. > It is confusing. I'm not an expert on this, but I can't see any use for this in sandbox. One problem might be that it should be using map_sysmem() instead of a cast. Regards, Simon
Re: [PATCH] sandbox: also restore terminal settings when killed by SIGINT
On Fri, 14 Feb 2020 at 03:58, Rasmus Villemoes wrote: > > Hitting Ctrl-C is a documented way to exit the sandbox, but it is not > actually equivalent to the reset command. The latter, since it follows > normal process exit, takes care to reset terminal settings and > restoring the O_NONBLOCK behaviour of stdin (and, in a terminal, that > is usually the same file description as stdout and stderr, i.e. some > /dev/pts/NN). > > Failure to restore (remove) O_NONBLOCK from stdout/stderr can cause > very surprising and hard to debug problems back in the terminal. For > example, I had "make -j8" consistently failing without much > information about just exactly what went wrong, but sometimes I did > get a "echo: write error". I was at first afraid my disk was getting > bad, but then a simple "dmesg" _also_ failed with write error - so it > was writing to the terminal that was buggered. And both "make -j8" and > dmesg in another terminal window worked just fine. > > So install a SIGINT handler so that if the chosen terminal > mode (cooked or raw-with-sigs) means Ctrl-C sends a SIGINT, we will > still call os_fd_restore(), then reraise the signal and die as usual > from SIGINT. > > Before: > > $ grep flags /proc/$$/fdinfo/1 > flags: 0102002 > $ ./u-boot > # hit Ctrl-C > $ grep flags /proc/$$/fdinfo/1 > flags: 0106002 > > After: > > $ grep flags /proc/$$/fdinfo/1 > flags: 0102002 > $ ./u-boot > # hit Ctrl-C > $ grep flags /proc/$$/fdinfo/1 > flags: 0102002 > > Signed-off-by: Rasmus Villemoes > --- > arch/sandbox/cpu/os.c | 9 + > 1 file changed, 9 insertions(+) Nice explanation, thank you. Reviewed-by: Simon Glass
Re: [PATCH] ARM: bootm: take into account gd->ram_top
Hi Patrick, On Thu, 13 Feb 2020 at 11:30, Patrick Delaunay wrote: > > From: Patrice Chotard > > If gd->ram_top has been tuned using board_get_usable_ram_top(), > it must be taken into account when reserving arch lmb. > > Signed-off-by: Patrice Chotard > Reviewed-by: Patrick DELAUNAY > Signed-off-by: Patrick Delaunay > --- > > arch/arm/lib/bootm.c | 3 +++ > 1 file changed, 3 insertions(+) Is this something we can test in test/lib/lmb.c ? Regards, Simon
Re: [PATCH] usb: dwc3: Check that the request is valid in dwc3_gadget_giveback()
On 2/14/20 1:23 PM, Vignesh Raghavendra wrote: > From: Jean-Jacques Hiblot > > This fixes potential issues reported by klokworks: > Pointer 'req' returned from call to function 'next_request' at line 531 and > 538 may be NULL and will be dereferenced in dwc3_gadget_giveback() Shouldn't you rather handle the issue in dwc3_remove_requests() ? Also, please explain what conditions trigger this issue, i.e. when req becomes NULL.
Re: [PATCH v3 0/5] usb: host: dwc2: use driver model for PHY and CLOCK
On 2/14/20 2:34 PM, Patrick DELAUNAY wrote: > Hi, [...] >> drivers/usb/host/dwc2.c | 100 >> +++- >> include/clk.h | 4 ++ >> 2 files changed, 103 insertions(+), 1 deletion(-) >> >> -- >> 2.17.1 > > Any comments on this serie or I need to rebase it and resend the serie ? > > http://patchwork.ozlabs.org/project/uboot/list/?series=142257 > > Sorry for the delay... > I miss the previous merge windows for v2020.01 and now I think it also the > case for v2020.04 ! Please rebase and repost, thanks. [...] -- Best regards, Marek Vasut
Re: RPI4: fail too boot with an initrd
Hi Corentin, On 14/02/2020 13:27, LABBE Corentin wrote: > Since the inclusion of the "enable network support in RPi4 config" serie on > uboot, I > have started to work on adding the rpi4 in kernelCI. > But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp. > > Using booti I hit: > [0.00] Linux version 5.6.0-rc1-next-20200212 > (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 > revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (LinaroGCC > 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020 > [0.00] Machine model: Raspberry Pi 4 Model B > [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '') > [0.00] printk: bootconsole [uart0] enabled > [0.00] efi: Getting EFI parameters from FDT: > [0.00] efi: UEFI not found. So no EFI, > [0.00] OF: reserved mem: failed to allocate memory for node > 'linux,cma' Out of memory. > [0.00] cma: Failed to reserve 32 MiB > [0.00] Kernel panic - not syncing: Failed to allocate page table page Out of memory... > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > 5.6.0-rc1-next-20200212 #66 > [0.00] Hardware name: Raspberry Pi 4 Model B (DT) > [0.00] Call trace: > [0.00] dump_backtrace+0x0/0x1a0 > [0.00] show_stack+0x14/0x20 > [0.00] dump_stack+0xbc/0x104 > [0.00] panic+0x16c/0x37c > [0.00] early_pgtable_alloc+0x30/0xa0 ... really early! > [0.00] __create_pgd_mapping+0x36c/0x588 > [0.00] map_kernel_segment+0x70/0xa4 > [0.00] paging_init+0xf4/0x528 > [0.00] setup_arch+0x250/0x5d8 > [0.00] start_kernel+0x90/0x6d8 > > > Since the same kernel boot with bootefi and that bootefi lack ramdisk address, Booting with EFI will cause linux to use the EFI memory map. Does your DT have a memory node? (or does it expect EFI to provide the information) > I tried to add the address in the dtb via: > fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start > 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 0x0008 > 0x0240 > But with that, I get: > initrd not fully accessible via the linear mapping -- please check your > bootloader ... So this one is an EFI boot, but you can't find where to put the initramfs such that the kernel agrees its in memory. If you boot with 'efi=debug', linux will print the EFI memory map. Could you compare that to where U-Boot thinks memory is? (it sounds like your DT memory node is missing, and your EFI memory map is surprisingly small) Thanks, James
[PATCH] image.h: Change android_image_get_dtb* to use uint and not u32
The image.h header can be used fairly widely in U-Boot builds. We cannot use u32 here as it may be used in cases where we don't have that typedef available and don't want to expose it either. Use uint instead here. Cc: Eugeniu Rosca Cc: Sam Protsenko Signed-off-by: Tom Rini --- include/image.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/image.h b/include/image.h index b316d167d8d7..1dc3b48d8689 100644 --- a/include/image.h +++ b/include/image.h @@ -1425,9 +1425,9 @@ int android_image_get_ramdisk(const struct andr_img_hdr *hdr, ulong *rd_data, ulong *rd_len); int android_image_get_second(const struct andr_img_hdr *hdr, ulong *second_data, ulong *second_len); -bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, u32 *size); -bool android_image_get_dtb_by_index(ulong hdr_addr, u32 index, ulong *addr, - u32 *size); +bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, uint *size); +bool android_image_get_dtb_by_index(ulong hdr_addr, uint index, ulong *addr, + uint *size); ulong android_image_get_end(const struct andr_img_hdr *hdr); ulong android_image_get_kload(const struct andr_img_hdr *hdr); ulong android_image_get_kcomp(const struct andr_img_hdr *hdr); -- 2.17.1
Re: [PATCH] arm: dts: imx8mq-evk: add phy-reset-gpios for fec1
Hi On Fri, Feb 14, 2020 at 6:33 PM Alifer Moraes wrote: > > Hello, Michael, > > > Where is the relative pinctrl change to mux the pin? why now is 10 the > > reset duration > > The pinctrl change is described in arch/arm/dts/imx8mq-evk.dts in the > subnode pinctrl_fec1. Ok, so was already defined the pinmux there. > The ethernet phy used by this board is an atheros 8031, its datasheet > says that the reset duration should be 10ms. Please upload the commit message with this information Michael PS: this way to reset is deprecated but uboot I think does not have the reset at mdio bus level > > Regards, > > Alifer -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com |
Re: [PATCH] arm: dts: imx8mq-evk: add phy-reset-gpios for fec1
Hi
On Fri, Feb 14, 2020 at 6:18 PM Alifer Moraes wrote:
>
> Let the driver reset the phy via dts description instead of doing it
> through functions in imx8mq_evk.c
>
> Signed-off-by: Alifer Moraes
> ---
> arch/arm/dts/imx8mq-evk.dts | 2 ++
> board/freescale/imx8mq_evk/imx8mq_evk.c | 18 --
> 2 files changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mq-evk.dts b/arch/arm/dts/imx8mq-evk.dts
> index 3693933451..55294ba9c8 100644
> --- a/arch/arm/dts/imx8mq-evk.dts
> +++ b/arch/arm/dts/imx8mq-evk.dts
> @@ -104,6 +104,8 @@
> pinctrl-0 = <_fec1>;
> phy-mode = "rgmii-id";
> phy-handle = <>;
> + phy-reset-gpios = < 9 GPIO_ACTIVE_LOW>;
> + phy-reset-duration = <10>;
Where is the relative pinctrl change to mux the pin? why now is 10 the
reset duration
Michael
> fsl,magic-packet;
> status = "okay";
>
> diff --git a/board/freescale/imx8mq_evk/imx8mq_evk.c
> b/board/freescale/imx8mq_evk/imx8mq_evk.c
> index cb39d0f2d6..b2f464abb1 100644
> --- a/board/freescale/imx8mq_evk/imx8mq_evk.c
> +++ b/board/freescale/imx8mq_evk/imx8mq_evk.c
> @@ -64,29 +64,11 @@ int dram_init(void)
> }
>
> #ifdef CONFIG_FEC_MXC
> -#define FEC_RST_PAD IMX_GPIO_NR(1, 9)
> -static iomux_v3_cfg_t const fec1_rst_pads[] = {
> - IMX8MQ_PAD_GPIO1_IO09__GPIO1_IO9 | MUX_PAD_CTRL(NO_PAD_CTRL),
> -};
> -
> -static void setup_iomux_fec(void)
> -{
> - imx_iomux_v3_setup_multiple_pads(fec1_rst_pads,
> -ARRAY_SIZE(fec1_rst_pads));
> -
> - gpio_request(IMX_GPIO_NR(1, 9), "fec1_rst");
> - gpio_direction_output(IMX_GPIO_NR(1, 9), 0);
> - udelay(500);
> - gpio_direction_output(IMX_GPIO_NR(1, 9), 1);
> -}
> -
> static int setup_fec(void)
> {
> struct iomuxc_gpr_base_regs *gpr =
> (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
>
> - setup_iomux_fec();
> -
> /* Use 125M anatop REF_CLK1 for ENET1, not from external */
> clrsetbits_le32(>gpr[1], BIT(13) | BIT(17), 0);
> return set_clk_enet(ENET_125MHZ);
> --
> 2.17.1
>
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
[PATCH] arm: dts: imx8mq-evk: add phy-reset-gpios for fec1
Let the driver reset the phy via dts description instead of doing it
through functions in imx8mq_evk.c
Signed-off-by: Alifer Moraes
---
arch/arm/dts/imx8mq-evk.dts | 2 ++
board/freescale/imx8mq_evk/imx8mq_evk.c | 18 --
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/arch/arm/dts/imx8mq-evk.dts b/arch/arm/dts/imx8mq-evk.dts
index 3693933451..55294ba9c8 100644
--- a/arch/arm/dts/imx8mq-evk.dts
+++ b/arch/arm/dts/imx8mq-evk.dts
@@ -104,6 +104,8 @@
pinctrl-0 = <_fec1>;
phy-mode = "rgmii-id";
phy-handle = <>;
+ phy-reset-gpios = < 9 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
fsl,magic-packet;
status = "okay";
diff --git a/board/freescale/imx8mq_evk/imx8mq_evk.c
b/board/freescale/imx8mq_evk/imx8mq_evk.c
index cb39d0f2d6..b2f464abb1 100644
--- a/board/freescale/imx8mq_evk/imx8mq_evk.c
+++ b/board/freescale/imx8mq_evk/imx8mq_evk.c
@@ -64,29 +64,11 @@ int dram_init(void)
}
#ifdef CONFIG_FEC_MXC
-#define FEC_RST_PAD IMX_GPIO_NR(1, 9)
-static iomux_v3_cfg_t const fec1_rst_pads[] = {
- IMX8MQ_PAD_GPIO1_IO09__GPIO1_IO9 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-static void setup_iomux_fec(void)
-{
- imx_iomux_v3_setup_multiple_pads(fec1_rst_pads,
-ARRAY_SIZE(fec1_rst_pads));
-
- gpio_request(IMX_GPIO_NR(1, 9), "fec1_rst");
- gpio_direction_output(IMX_GPIO_NR(1, 9), 0);
- udelay(500);
- gpio_direction_output(IMX_GPIO_NR(1, 9), 1);
-}
-
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *gpr =
(struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
- setup_iomux_fec();
-
/* Use 125M anatop REF_CLK1 for ENET1, not from external */
clrsetbits_le32(>gpr[1], BIT(13) | BIT(17), 0);
return set_clk_enet(ENET_125MHZ);
--
2.17.1
Re: i.MX8QXP MEK does not boot
On Fri, Feb 14, 2020 at 10:55 AM Fabio Estevam wrote: > > Hi Anatolij, > > On Fri, Feb 14, 2020 at 7:25 AM Anatolij Gustschin wrote: > > > We have two issues here, power domain off hang reported here [1] > > and disabling nodes in device tree since commit 9f779fa4105f. > > If I try reverting these two commits the kernel starts booting: > http://code.bulix.org/0xmech-1126740 > > but it stops when the LPUART is probed. The boot succeeds if I use a NXP based 4.14.98 kernel though. It fails with mainline and NXP 4.19.
Re: [PATCH v5] Add support for SoM "VoCore2".
Hi Daniel, On 2/12/20 11:01 PM, Mauro Condarelli wrote: >>> + >>> +/* SPL */ >>> +#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD) >>> +#define CONFIG_SKIP_LOWLEVEL_INIT >>> +#endif >> CONFIG_SPL_BUILD is only relevant in Makefiles and shouldn't be used >> in config header files > Removed, apparently without adverse consequences. Appearence was misguiding. Any change to this guard leads to code unable to boot from SPI NOR. I'll have to leave it is as-is. Someone more knowledgeable than me will have to understand why they are needed and how to remove them, if that's a requirement. After all the other boards with this SoC use the same code. Regards Mauro
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Thu, Feb 13, 2020 at 11:32:52PM +0200, David Abdurachmanov wrote:
> On Thu, Feb 13, 2020 at 6:17 PM Tom Rini wrote:
> >
> > On Wed, Feb 05, 2020 at 12:01:38AM +, Atish Patra wrote:
> > > On Fri, 2019-11-22 at 18:19 -0800, Atish Patra wrote:
> > > > On Wed, 2019-11-13 at 11:47 -0800, Atish Patra wrote:
> > > > > On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov wrote:
> > > > > > On Sat, Nov 9, 2019 at 2:14 AM Atish Patra
> > > > > > wrote:
> > > > > > > Add compressed Image parsing support so that booti can parse
> > > > > > > both
> > > > > > > flat and compressed Image to boot Linux. Currently, it is
> > > > > > > difficult
> > > > > > > to calculate a safe address for every board where the
> > > > > > > compressed
> > > > > > > image can be decompressed. It is also not possible to figure
> > > > > > > out
> > > > > > > the
> > > > > > > size of the compressed file as well. Thus, user need to set two
> > > > > > > additional environment variables kernel_comp_addr_r and
> > > > > > > filesize
> > > > > > > to
> > > > > > > make this work.
> > > > > > >
> > > > > > > Following compression methods are supported for now.
> > > > > > > lzma, lzo, bzip2, gzip.
> > > > > > >
> > > > > > > lz4 support is not added as ARM64 kernel generates a lz4
> > > > > > > compressed
> > > > > > > image with legacy header which U-Boot doesn't know how to parse
> > > > > > > and
> > > > > > > decompress.
> > > > > > >
> > > > > > > Tested on HiFive Unleashed and Qemu for RISC-V.
> > > > > > > Tested on Qemu for ARM64.
> > > > > > >
> > > > > > > Signed-off-by: Atish Patra
> > > > > > > ---
> > > > > > > I could not test this patch on any ARM64 boards due to lack of
> > > > > > > access to any ARM64 board. If anybody can test it on ARM64,
> > > > > > > that
> > > > > > > would be great.
> > > > > > > ---
> > > > > > > cmd/booti.c| 40 ++-
> > > > > > > doc/README.distro | 12 +
> > > > > > > doc/board/sifive/fu540.rst | 55
> > > > > > > ++
> > > > > > > 3 files changed, 106 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/cmd/booti.c b/cmd/booti.c
> > > > > > > index c36b0235df8c..cd8670a9a8db 100644
> > > > > > > --- a/cmd/booti.c
> > > > > > > +++ b/cmd/booti.c
> > > > > > > @@ -13,6 +13,7 @@
> > > > > > > #include
> > > > > > > #include
> > > > > > >
> > > > > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > > > > /*
> > > > > > > * Image booting support
> > > > > > > */
> > > > > > > @@ -23,6 +24,12 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > > > > > > flag, int argc,
> > > > > > > ulong ld;
> > > > > > > ulong relocated_addr;
> > > > > > > ulong image_size;
> > > > > > > + uint8_t *temp;
> > > > > > > + ulong dest;
> > > > > > > + ulong dest_end;
> > > > > > > + unsigned long comp_len;
> > > > > > > + unsigned long decomp_len;
> > > > > > > + int ctype;
> > > > > > >
> > > > > > > ret = do_bootm_states(cmdtp, flag, argc, argv,
> > > > > > > BOOTM_STATE_START,
> > > > > > > images, 1);
> > > > > > > @@ -37,6 +44,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > > > > > > flag, int argc,
> > > > > > > debug("* kernel: cmdline image address =
> > > > > > > 0x%08lx\n", ld);
> > > > > > > }
> > > > > > >
> > > > > > > + temp = map_sysmem(ld, 0);
> > > > > > > + ctype = image_decomp_type(temp, 2);
> > > > > > > + if (ctype > 0) {
> > > > > > > + dest = env_get_ulong("kernel_comp_addr_r", 16,
> > > > > > > 0);
> > > > > > > + comp_len = env_get_ulong("filesize", 16, 0);
> > > > > > > + if (!dest || !comp_len) {
> > > > > > > + puts("kernel_comp_addr_r or filesize is
> > > > > > > not
> > > > > > > provided!\n");
> > > > > > > + return -EINVAL;
> > > > > > > + }
> > > > > > > + if (dest < gd->ram_base || dest > gd->ram_top)
> > > > > > > {
> > > > > > > + puts("kernel_comp_addr_r is outside of
> > > > > > > DRAM
> > > > > > > range!\n");
> > > > > > > + return -EINVAL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + debug("kernel image compression type %d size =
> > > > > > > 0x%08lx address = 0x%08lx\n",
> > > > > > > + ctype, comp_len, (ulong)dest);
> > > > > > > + decomp_len = comp_len * 10;
> > > > > > > + ret = image_decomp(ctype, 0, ld,
> > > > > > > IH_TYPE_KERNEL,
> > > > > > > +(void *)dest, (void *)ld,
> > > > > > > comp_len,
> > > > > > > +decomp_len, _end);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > + /* dest_end contains the uncompressed Image
> > > > > > > size
> > > >
[PATCH 3/3] imx: imx8mn-evk: enable ethernet
Enable ethernet on i.MX 8MN EVK
Signed-off-by: Alifer Moraes
---
arch/arm/dts/imx8mn-ddr4-evk.dts| 2 ++
board/freescale/imx8mn_evk/imx8mn_evk.c | 36 +
configs/imx8mn_ddr4_evk_defconfig | 8 ++
include/configs/imx8mn_evk.h| 2 ++
4 files changed, 48 insertions(+)
diff --git a/arch/arm/dts/imx8mn-ddr4-evk.dts b/arch/arm/dts/imx8mn-ddr4-evk.dts
index 9b2c1727a8..53ce10b13d 100644
--- a/arch/arm/dts/imx8mn-ddr4-evk.dts
+++ b/arch/arm/dts/imx8mn-ddr4-evk.dts
@@ -165,6 +165,8 @@
pinctrl-0 = <_fec1>;
phy-mode = "rgmii-id";
phy-handle = <>;
+ phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
fsl,magic-packet;
status = "okay";
diff --git a/board/freescale/imx8mn_evk/imx8mn_evk.c
b/board/freescale/imx8mn_evk/imx8mn_evk.c
index 4f33c0e7c9..9ff1dc8555 100644
--- a/board/freescale/imx8mn_evk/imx8mn_evk.c
+++ b/board/freescale/imx8mn_evk/imx8mn_evk.c
@@ -4,6 +4,10 @@
*/
#include
+#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -14,8 +18,40 @@ int dram_init(void)
return 0;
}
+#if IS_ENABLED(CONFIG_FEC_MXC)
+static int setup_fec(void)
+{
+ struct iomuxc_gpr_base_regs *gpr =
+ (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
+
+ /* Use 125M anatop REF_CLK1 for ENET1, not from external */
+ clrsetbits_le32(>gpr[1], 0x2000, 0);
+
+ return 0;
+}
+
+int board_phy_config(struct phy_device *phydev)
+{
+ /* enable rgmii rxc skew and phy mode select to RGMII copper */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x1f);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x8);
+
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x00);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x82ee);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100);
+
+ if (phydev->drv->config)
+ phydev->drv->config(phydev);
+ return 0;
+}
+#endif
+
int board_init(void)
{
+ if (IS_ENABLED(CONFIG_FEC_MXC))
+ setup_fec();
+
return 0;
}
diff --git a/configs/imx8mn_ddr4_evk_defconfig
b/configs/imx8mn_ddr4_evk_defconfig
index e3f99896a6..0e21283d58 100644
--- a/configs/imx8mn_ddr4_evk_defconfig
+++ b/configs/imx8mn_ddr4_evk_defconfig
@@ -43,6 +43,9 @@ CONFIG_CMD_FUSE=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_I2C=y
CONFIG_CMD_MMC=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_REGULATOR=y
CONFIG_CMD_EXT2=y
@@ -67,7 +70,12 @@ CONFIG_DM_MMC=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_FSL_ESDHC_IMX=y
CONFIG_PHYLIB=y
+CONFIG_PHY_ATHEROS=y
CONFIG_DM_ETH=y
+CONFIG_PHY_GIGE=y
+CONFIG_FEC_MXC=y
+CONFIG_MII=y
+CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_PINCTRL=y
CONFIG_SPL_PINCTRL=y
CONFIG_PINCTRL_IMX8M=y
diff --git a/include/configs/imx8mn_evk.h b/include/configs/imx8mn_evk.h
index ce73ca6b0a..bfc1a55637 100644
--- a/include/configs/imx8mn_evk.h
+++ b/include/configs/imx8mn_evk.h
@@ -149,4 +149,6 @@
#define CONFIG_SYS_I2C_SPEED 10
+#define FEC_QUIRK_ENET_MAC
+
#endif
--
2.17.1
[PATCH 2/3] clk: imx: imx8mn: add set_parent callback
Add set_parent callback, then assigned-clock-parents in dts could work properly
Signed-off-by: Alifer Moraes
---
drivers/clk/imx/clk-imx8mn.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index 103ba770ed..2abd9a3810 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -175,11 +175,30 @@ static int imx8mn_clk_enable(struct clk *clk)
return __imx8mn_clk_enable(clk, 1);
}
+static int imx8mn_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ struct clk *c, *cp;
+ int ret;
+
+ debug("%s(#%lu), parent: %lu\n", __func__, clk->id, parent->id);
+
+ ret = clk_get_by_id(clk->id, );
+ if (ret)
+ return ret;
+
+ ret = clk_get_by_id(parent->id, );
+ if (ret)
+ return ret;
+
+ return clk_set_parent(c, cp);
+}
+
static struct clk_ops imx8mn_clk_ops = {
.set_rate = imx8mn_clk_set_rate,
.get_rate = imx8mn_clk_get_rate,
.enable = imx8mn_clk_enable,
.disable = imx8mn_clk_disable,
+ .set_parent = imx8mn_clk_set_parent,
};
static int imx8mn_clk_probe(struct udevice *dev)
--
2.17.1
[PATCH 1/3] clk: imx: imx8mn: add enet clk
Add enet ref/timer/PHY_REF/root clk wich are required to make enet work properly
Signed-off-by: Alifer Moraes
---
drivers/clk/imx/clk-imx8mn.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index eb43971ae6..103ba770ed 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -80,6 +80,17 @@ static const char *imx8mn_ahb_sels[] = {"clock-osc-24m",
"sys_pll1_133m", "sys_p
static const char *imx8mn_enet_axi_sels[] = {"clock-osc-24m", "sys_pll1_266m",
"sys_pll1_800m", "sys_pll2_250m",
"sys_pll2_200m", "audio_pll1_out",
"video_pll1_out", "sys_pll3_out", };
+#ifndef CONFIG_SPL_BUILD
+static const char *imx8mn_enet_ref_sels[] = {"clock-osc-24m", "sys_pll2_125m",
"sys_pll2_50m", "sys_pll2_100m",
+"sys_pll1_160m", "audio_pll1_out",
"video_pll1_out", "clk_ext4", };
+
+static const char *imx8mn_enet_timer_sels[] = {"clock-osc-24m",
"sys_pll2_100m", "audio_pll1_out", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"video_pll1_out", };
+
+static const char *imx8mn_enet_phy_sels[] = {"clock-osc-24m", "sys_pll2_50m",
"sys_pll2_125m", "sys_pll2_200m",
+"sys_pll2_500m", "video_pll1_out",
"audio_pll2_out", };
+#endif
+
static const char *imx8mn_nand_usdhc_sels[] = {"clock-osc-24m",
"sys_pll1_266m", "sys_pll1_800m", "sys_pll2_200m",
"sys_pll1_133m", "sys_pll3_out",
"sys_pll2_250m", "audio_pll1_out", };
@@ -363,6 +374,14 @@ static int imx8mn_clk_probe(struct udevice *dev)
clk_dm(IMX8MN_CLK_USDHC3_ROOT,
imx_clk_gate4("usdhc3_root_clk", "usdhc3", base + 0x45e0, 0));
+/* clks not needed in SPL stage */
+#ifndef CONFIG_SPL_BUILD
+ clk_dm(IMX8MN_CLK_ENET_REF, imx8m_clk_composite("enet_ref",
imx8mn_enet_ref_sels, base + 0xa980));
+ clk_dm(IMX8MN_CLK_ENET_TIMER, imx8m_clk_composite("enet_timer",
imx8mn_enet_timer_sels, base + 0xaa00));
+ clk_dm(IMX8MN_CLK_ENET_PHY_REF, imx8m_clk_composite("enet_phy",
imx8mn_enet_phy_sels, base + 0xaa80));
+ clk_dm(IMX8MN_CLK_ENET1_ROOT, imx_clk_gate4("enet1_root_clk",
"enet_axi", base + 0x40a0, 0));
+#endif
+
#ifdef CONFIG_SPL_BUILD
struct clk *clkp, *clkp1;
--
2.17.1
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
> Am 14.02.2020 um 15:43 schrieb Tom Rini :
>
> On Fri, Feb 14, 2020 at 03:40:05PM +0100, Jens Rehsack wrote:
>>
>>
>>> Am 14.02.2020 um 15:28 schrieb Tom Rini :
>>>
>>> On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote:
> Am 14.02.2020 um 14:45 schrieb Tom Rini :
>
> On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
>> On 14. 02. 20 12:37, Jens Rehsack wrote:
>>>
>>>
Am 14.02.2020 um 10:36 schrieb Michal Simek :
On 13. 02. 20 18:48, Tom Rini wrote:
> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
>>
>>
>>> Am 13.02.2020 um 16:01 schrieb Tom Rini :
>>>
>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
>>>
From: Jens Rehsack
Introduce SUPPLIER analogous to VENDOR to allow (from customer
perspective)
a VENDOR using it's SUPPLIER's common/ code.
This is reasonable, when a VENDOR (from customer perspective)
builds
several machines sharing some features (e.g. some FPGA which has
to be
initialized during u-boot) but wants to use common NXP or Samsung
code
for the BSP instead of copying and create merge overhead.
Signed-off-by: Jens Rehsack
---
Makefile | 4 +++-
arch/Kconfig | 12
config.mk| 6 +-
3 files changed, 20 insertions(+), 2 deletions(-)
>>>
>>> Can you provide a follow-up where this it clearer / easier to do
>>> something than today? Thanks!
>>
>> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
>> NXP code for the Management Complex is needed. I2C code either - this
>> covers board/freescale/common/...
>>
>> Given you build machines from there with different SoCs under a
>> new label - let's call it SuperLink, so you have
>> * board/freescale/common
>> * board/superlink/common
>> * board/superlink/legacy-tune <-- based on some PowerPC
>> * board/superlink/easy-tune <-- based on LS2088
>> * board/superlink/heavy-tune <-- based on LX2160
>>
>> All *-tune machines the customer buys from SuperLink have a
>> similar FPGA (there is a little bit more, but for the vision
>> it's probably better to stay small) and a similar external
>> PMIC/BMC.
>>
>> But SuperLink still uses code from board/freescale/common (their
>> supplier) and it's not reasonable to copy those.
>>
>> I rate all this not suitable for a commit message. How do
>> you suggest to proceed?
>
> Well, lets add in Michal as there are Zynq examples that could be
> cleaned up with what you're proposing. Similarly, Vanessa and Otavio
> might have thoughts here as they could rework some of the TechNexion
> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be
> moved
> from board/ to some sub-directory?). Thanks all!
I think it will be the best to take any of your example and simply
create a series where this is applied to see if that code looks better
then before. Applying this without usage doesn't make sense.
>>>
>>> I don't understand what you propose. Do you ask me to show internal
>>> sources or the result of `find {...} -type f` or the content of our
>>> Kconfig or defconfig?
>>>
>>> I'll try to do as much as I can (I'm sure, showing internal code won't
>>> be permitted).
>>>
For zynq there are some boards like topic, bitmain, opalkelly which
are
staying in own folder but sourcing zynq board.c.
>>>
>>> As said, freescale common code stays in board/freescale/common/ - and
>>> our code is in board/"superlink"/...
>>
>> I expect that you will find any example in the current code which can
>> use this feature. It means you can enable this feature and any current
>> configuration will really use it and will be regularly used/covered by
>> testing.
>> Adding feature which none will use in mainline should be IMHO nacked.
>
> Yes. All of the boards / people I added to the thread here have
> platforms that would be able to leverage this idea, so I was hoping they
> might have a perspective on if it would be clear than just:
> obj-y += ../..//common/whatever.o
> like is done today.
So a PATCH-set with (likely non-working) examples will be fine or not?
>>>
>>> No, but there are a number of existing configs that could be changed to
>>> use the framework you're suggesting. So far it seems like the feedback
>>>
Re: [PATCHv2 2/7] misc: k3_esm: Add support for Texas Instruments K3 ESM driver
On Fri, Feb 14, 2020 at 11:18:15AM +0200, Tero Kristo wrote:
> The ESM (Error Signaling Module) is used to route error signals within
> the K3 SoCs somewhat similar to interrupts. The handling for these is
> different though, and can be routed for hardware error handling, to
> be handled by safety processor or just as error interrupts handled
> by the main processor. The u-boot level ESM driver is just used to
> configure the ESM signals so that they get routed to proper destination.
>
> Signed-off-by: Tero Kristo
> ---
> doc/device-tree-bindings/misc/esm-k3.txt | 25 +++
> drivers/misc/Kconfig | 5 ++
> drivers/misc/Makefile| 1 +
> drivers/misc/k3_esm.c| 87
> 4 files changed, 118 insertions(+)
> create mode 100644 doc/device-tree-bindings/misc/esm-k3.txt
> create mode 100644 drivers/misc/k3_esm.c
>
> diff --git a/doc/device-tree-bindings/misc/esm-k3.txt
> b/doc/device-tree-bindings/misc/esm-k3.txt
> new file mode 100644
> index 00..01c8b6b294
> --- /dev/null
> +++ b/doc/device-tree-bindings/misc/esm-k3.txt
> @@ -0,0 +1,25 @@
> +Texas Instruments K3 ESM Binding
> +==
> +
> +ESM (Error Signaling Module) is an IP block on TI K3 devices that allows
> +handling of safety events somewhat similar to what interrupt controller
> +would do. The safety signals have their separate paths within the SoC,
> +and they are handled by the ESM, which routes them to the proper
> +destination, which can be system reset, interrupt controller, etc. In
> +the simplest configuration the signals are just routed to reset the
> +SoC.
> +
> +Required properties :
> +- compatible : "ti,j721e-esm"
> +- ti,esm-pins: integer array of esm events IDs to route to external
> event
> + pin which can be used to reset the SoC. The array can
> + have arbitrary amount of event IDs listed on it.
> +
> +Example
> +===
> +
> + main_esm: esm@70 {
> + compatible = "ti,j721e-esm";
> + reg = <0x0 0x70 0x0 0x1000>;
> + ti,esm-pins = <344>, <345>;
> + };
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index f18aa8f7ba..38588b2cbd 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -462,6 +462,11 @@ config IHS_FPGA
> gdsys devices, which supply the majority of the functionality offered
> by the devices. This driver supports both CON and CPU variants of the
> devices, depending on the device tree entry.
missing space.
Otherwise:
Reviewed-by: Tom Rini
And if there's no other feedback, Lokesh, please just fix that up when
applying, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PULL] Pull request: u-boot-stm32 u-boot-stm32-20200214
On Fri, Feb 14, 2020 at 10:11:23AM +, Patrick DELAUNAY wrote: > Hi Tom, > > Please pull the STM32 related patches for u-boot-stm32-20200214 > for v2020.04-rc3 > > With the following changes: > - add DH Electronics DHCOM SoM and PDK2 board > - DT alignment with kernel v5.5-rc7 for stm32mp1 boards > - fix STM32 image format for big endian hosts in mkimage > - solve warnings in device tree and code for stm32mp1 boards > - remove fdt_high and initrd_high for stm32 and stih boards > - add support of STM32MP15x Rev.Z > - update stm32mp1 readme > > CI status: > https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2194 > > Thanks, > Patrick > > The following changes since commit 721d6b594be4dc2d13b61f6afee9e437278d3ddd: > > Prepare v2020.04-rc2 (2020-02-12 09:30:43 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20200214 > > for you to fetch changes up to 8ee5e3c81f47b8647ef05219058d260199c51d1b: > > board: stm32: remove fdt_high and fdt_highinitrd_high (2020-02-13 18:47:00 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] TI changes for v2020.04-rc3
On Fri, Feb 14, 2020 at 03:19:43PM +0530, Lokesh Vutla wrote: > Hi Tom, > > Please find the pull request for v2020.04-rc3 containing TI specific changes. > > Travis-CI build: https://travis-ci.org/lokeshvutla/u-boot/builds/650270755 > > Thanks and regards, > Lokesh > > > The following changes since commit 01e7a40e395aefea94e9fb943b9447f7d0fd7efa: > > Merge tag 'arc-fixes-for-2020.04-rc2' of > https://gitlab.denx.de/u-boot/custodians/u-boot-arc (2020-02-12 17:20:25 > -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.04-rc3 > > for you to fetch changes up to 96dd223c2933a9190411f52ab0654f50feca3005: > > armV7R: K3: am654: Activate early console functionality (2020-02-13 > 21:39:18 +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v1 0/2] Add roc-rk3328-cc support
This serie add support for roc-rk33239 board from Firefly/Libre Computer: - add missing L2 cache entry in rk3328 dts - add roc-rk3328-cc board support With this we can successfully boot the board with mainline U-Boot and binary blob firmwares. Boot with ATF and TPL/SPL partially works: TPL works fine but SPL fails to find a bootable device. I didn't used the DTS from Linux kernel: USB2 fails in that case, this should be corrected but maybe later? Note: sorry if this serie has been send twice, but I had issue with my email server... Loic Devulder (2): rockchip: rk3328: dts: add L2 cache entry rockchip: rk3328: add roc-rk3328-cc support arch/arm/dts/Makefile | 3 +- arch/arm/dts/rk3328-roc-cc-u-boot.dtsi | 16 ++ arch/arm/dts/rk3328-roc-cc.dts | 260 + arch/arm/dts/rk3328.dtsi | 25 ++- arch/arm/mach-rockchip/rk3328/Kconfig | 1 - board/rockchip/evb_rk3328/MAINTAINERS | 6 + configs/roc-cc-rk3328_defconfig| 95 + doc/README.rockchip| 9 +- 8 files changed, 408 insertions(+), 7 deletions(-) create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi create mode 100644 arch/arm/dts/rk3328-roc-cc.dts create mode 100644 configs/roc-cc-rk3328_defconfig -- 2.25.0
[PATCH v1 1/2] rockchip: rk3328: dts: add L2 cache entry
Add missing L2 cache entry in dts to avoid warning during Linux
kernel boot.
Signed-off-by: Loic Devulder
---
arch/arm/dts/rk3328.dtsi | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index 060c84e6c0..7334eb124d 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
@@ -38,7 +38,10 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
-// clocks = < ARMCLK>;
+ clocks = < ARMCLK>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <120>;
+ next-level-cache = <>;
operating-points-v2 = <_opp_table>;
};
cpu1: cpu@1 {
@@ -46,19 +49,39 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ clocks = < ARMCLK>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <120>;
+ next-level-cache = <>;
+ operating-points-v2 = <_opp_table>;
};
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ clocks = < ARMCLK>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <120>;
+ next-level-cache = <>;
+ operating-points-v2 = <_opp_table>;
};
cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ clocks = < ARMCLK>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <120>;
+ next-level-cache = <>;
+ operating-points-v2 = <_opp_table>;
};
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+
};
cpu0_opp_table: opp_table0 {
--
2.25.0
[PATCH v1 2/2] rockchip: rk3328: add roc-rk3328-cc support
ROC-RK3328-CC is a board made by Firefly/Libre Computer based on rk3328
SoC:
- 2 USB2.0 Host port
- 1 USB3.0 Host port
- 1 HDMI port
- 2 10/100M eth port
- 1GB or 2GB DDR4
- UART to USB debug port
This port is based on evb-rk3328 already available in U-Boot.
Signed-off-by: Loic Devulder
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/rk3328-roc-cc-u-boot.dtsi | 16 ++
arch/arm/dts/rk3328-roc-cc.dts | 260 +
arch/arm/mach-rockchip/rk3328/Kconfig | 1 -
board/rockchip/evb_rk3328/MAINTAINERS | 6 +
configs/roc-cc-rk3328_defconfig| 95 +
doc/README.rockchip| 9 +-
7 files changed, 384 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
create mode 100644 configs/roc-cc-rk3328_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4fee5cc489..db4b987c4c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -104,7 +104,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
- rk3328-rock64.dtb
+ rk3328-rock64.dtb \
+ rk3328-roc-cc.dtb
dtb-$(CONFIG_ROCKCHIP_RK3368) += \
rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
new file mode 100644
index 00..cf3452ea94
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+_host0_xhci {
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
new file mode 100644
index 00..2bfb261bad
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+ model = "Firefly ROC-RK3328-CC";
+ compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
+ chosen {
+ stdout-path =
+ };
+
+ gmac_clkin: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_clkin";
+ #clock-cells = <0>;
+ };
+
+ vcc3v3_sdmmc: sdmmc-pwren {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ gpio = < 30 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc5v0_otg: vcc5v0-otg-drv {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ regulator-name = "vcc5v0_otg";
+ gpio = < 26 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+ status = "disabled";//usb host xhci and usb otg use the
same gpio to enable power
+ compatible = "regulator-fixed";
+ enable-active-high;
+ regulator-name = "vcc5v0_host_xhci";
+ gpio = < 26 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 0>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
+
+ {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ disable-wp;
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_clk>, <_cmd>, <_dectn>,
<_bus4>;
+ status = "okay";
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ supports-emmc;
+ disable-wp;
+ non-removable;
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_clk _cmd _bus8>;
+ status = "okay";
+};
+
+ {
+phy-supply = <_phy>;
+phy-mode = "rgmii";
+clock_in_out = "input";
+snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
+snps,reset-active-low;
+snps,reset-delays-us = <0 1 5>;
+assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
+assigned-clock-parents = <_clkin>, <_clkin>;
+pinctrl-names = "default";
+
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
On Fri, Feb 14, 2020 at 03:40:05PM +0100, Jens Rehsack wrote:
>
>
> > Am 14.02.2020 um 15:28 schrieb Tom Rini :
> >
> > On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote:
> >>
> >>
> >>> Am 14.02.2020 um 14:45 schrieb Tom Rini :
> >>>
> >>> On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
> On 14. 02. 20 12:37, Jens Rehsack wrote:
> >
> >
> >> Am 14.02.2020 um 10:36 schrieb Michal Simek :
> >>
> >> On 13. 02. 20 18:48, Tom Rini wrote:
> >>> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
>
>
> > Am 13.02.2020 um 16:01 schrieb Tom Rini :
> >
> > On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
> >
> >> From: Jens Rehsack
> >>
> >> Introduce SUPPLIER analogous to VENDOR to allow (from customer
> >> perspective)
> >> a VENDOR using it's SUPPLIER's common/ code.
> >>
> >> This is reasonable, when a VENDOR (from customer perspective)
> >> builds
> >> several machines sharing some features (e.g. some FPGA which has
> >> to be
> >> initialized during u-boot) but wants to use common NXP or Samsung
> >> code
> >> for the BSP instead of copying and create merge overhead.
> >>
> >> Signed-off-by: Jens Rehsack
> >> ---
> >> Makefile | 4 +++-
> >> arch/Kconfig | 12
> >> config.mk| 6 +-
> >> 3 files changed, 20 insertions(+), 2 deletions(-)
> >
> > Can you provide a follow-up where this it clearer / easier to do
> > something than today? Thanks!
>
> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
> NXP code for the Management Complex is needed. I2C code either - this
> covers board/freescale/common/...
>
> Given you build machines from there with different SoCs under a
> new label - let's call it SuperLink, so you have
> * board/freescale/common
> * board/superlink/common
> * board/superlink/legacy-tune <-- based on some PowerPC
> * board/superlink/easy-tune <-- based on LS2088
> * board/superlink/heavy-tune <-- based on LX2160
>
> All *-tune machines the customer buys from SuperLink have a
> similar FPGA (there is a little bit more, but for the vision
> it's probably better to stay small) and a similar external
> PMIC/BMC.
>
> But SuperLink still uses code from board/freescale/common (their
> supplier) and it's not reasonable to copy those.
>
> I rate all this not suitable for a commit message. How do
> you suggest to proceed?
> >>>
> >>> Well, lets add in Michal as there are Zynq examples that could be
> >>> cleaned up with what you're proposing. Similarly, Vanessa and Otavio
> >>> might have thoughts here as they could rework some of the TechNexion
> >>> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be
> >>> moved
> >>> from board/ to some sub-directory?). Thanks all!
> >>
> >> I think it will be the best to take any of your example and simply
> >> create a series where this is applied to see if that code looks better
> >> then before. Applying this without usage doesn't make sense.
> >
> > I don't understand what you propose. Do you ask me to show internal
> > sources or the result of `find {...} -type f` or the content of our
> > Kconfig or defconfig?
> >
> > I'll try to do as much as I can (I'm sure, showing internal code won't
> > be permitted).
> >
> >> For zynq there are some boards like topic, bitmain, opalkelly which
> >> are
> >> staying in own folder but sourcing zynq board.c.
> >
> > As said, freescale common code stays in board/freescale/common/ - and
> > our code is in board/"superlink"/...
>
> I expect that you will find any example in the current code which can
> use this feature. It means you can enable this feature and any current
> configuration will really use it and will be regularly used/covered by
> testing.
> Adding feature which none will use in mainline should be IMHO nacked.
> >>>
> >>> Yes. All of the boards / people I added to the thread here have
> >>> platforms that would be able to leverage this idea, so I was hoping they
> >>> might have a perspective on if it would be clear than just:
> >>> obj-y += ../..//common/whatever.o
> >>> like is done today.
> >>
> >> So a PATCH-set with (likely non-working) examples will be fine or not?
> >
> > No, but there are a number of existing configs that could be changed to
> > use the framework you're suggesting. So far it seems like the feedback
> > has been that maybe this would be cleaner than just
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
> Am 14.02.2020 um 15:28 schrieb Tom Rini :
>
> On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote:
>>
>>
>>> Am 14.02.2020 um 14:45 schrieb Tom Rini :
>>>
>>> On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
On 14. 02. 20 12:37, Jens Rehsack wrote:
>
>
>> Am 14.02.2020 um 10:36 schrieb Michal Simek :
>>
>> On 13. 02. 20 18:48, Tom Rini wrote:
>>> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
> Am 13.02.2020 um 16:01 schrieb Tom Rini :
>
> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
>
>> From: Jens Rehsack
>>
>> Introduce SUPPLIER analogous to VENDOR to allow (from customer
>> perspective)
>> a VENDOR using it's SUPPLIER's common/ code.
>>
>> This is reasonable, when a VENDOR (from customer perspective) builds
>> several machines sharing some features (e.g. some FPGA which has to
>> be
>> initialized during u-boot) but wants to use common NXP or Samsung
>> code
>> for the BSP instead of copying and create merge overhead.
>>
>> Signed-off-by: Jens Rehsack
>> ---
>> Makefile | 4 +++-
>> arch/Kconfig | 12
>> config.mk| 6 +-
>> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> Can you provide a follow-up where this it clearer / easier to do
> something than today? Thanks!
Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
NXP code for the Management Complex is needed. I2C code either - this
covers board/freescale/common/...
Given you build machines from there with different SoCs under a
new label - let's call it SuperLink, so you have
* board/freescale/common
* board/superlink/common
* board/superlink/legacy-tune <-- based on some PowerPC
* board/superlink/easy-tune <-- based on LS2088
* board/superlink/heavy-tune <-- based on LX2160
All *-tune machines the customer buys from SuperLink have a
similar FPGA (there is a little bit more, but for the vision
it's probably better to stay small) and a similar external
PMIC/BMC.
But SuperLink still uses code from board/freescale/common (their
supplier) and it's not reasonable to copy those.
I rate all this not suitable for a commit message. How do
you suggest to proceed?
>>>
>>> Well, lets add in Michal as there are Zynq examples that could be
>>> cleaned up with what you're proposing. Similarly, Vanessa and Otavio
>>> might have thoughts here as they could rework some of the TechNexion
>>> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved
>>> from board/ to some sub-directory?). Thanks all!
>>
>> I think it will be the best to take any of your example and simply
>> create a series where this is applied to see if that code looks better
>> then before. Applying this without usage doesn't make sense.
>
> I don't understand what you propose. Do you ask me to show internal
> sources or the result of `find {...} -type f` or the content of our
> Kconfig or defconfig?
>
> I'll try to do as much as I can (I'm sure, showing internal code won't
> be permitted).
>
>> For zynq there are some boards like topic, bitmain, opalkelly which are
>> staying in own folder but sourcing zynq board.c.
>
> As said, freescale common code stays in board/freescale/common/ - and
> our code is in board/"superlink"/...
I expect that you will find any example in the current code which can
use this feature. It means you can enable this feature and any current
configuration will really use it and will be regularly used/covered by
testing.
Adding feature which none will use in mainline should be IMHO nacked.
>>>
>>> Yes. All of the boards / people I added to the thread here have
>>> platforms that would be able to leverage this idea, so I was hoping they
>>> might have a perspective on if it would be clear than just:
>>> obj-y += ../..//common/whatever.o
>>> like is done today.
>>
>> So a PATCH-set with (likely non-working) examples will be fine or not?
>
> No, but there are a number of existing configs that could be changed to
> use the framework you're suggesting. So far it seems like the feedback
> has been that maybe this would be cleaner than just what I said above,
> but you need to convert some of them to use this, so we can see if it's
> really cleaner or not.
Yes, but I do not intend to refactor u-boot code. I'm not qualified to do that.
Further: I'm in such a case not sure if it's the right tactic.
Since the SYS_SUPPLIER is introduced to have a 2nd
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote:
>
>
> > Am 14.02.2020 um 14:45 schrieb Tom Rini :
> >
> > On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
> >> On 14. 02. 20 12:37, Jens Rehsack wrote:
> >>>
> >>>
> Am 14.02.2020 um 10:36 schrieb Michal Simek :
>
> On 13. 02. 20 18:48, Tom Rini wrote:
> > On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
> >>
> >>
> >>> Am 13.02.2020 um 16:01 schrieb Tom Rini :
> >>>
> >>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
> >>>
> From: Jens Rehsack
>
> Introduce SUPPLIER analogous to VENDOR to allow (from customer
> perspective)
> a VENDOR using it's SUPPLIER's common/ code.
>
> This is reasonable, when a VENDOR (from customer perspective) builds
> several machines sharing some features (e.g. some FPGA which has to
> be
> initialized during u-boot) but wants to use common NXP or Samsung
> code
> for the BSP instead of copying and create merge overhead.
>
> Signed-off-by: Jens Rehsack
> ---
> Makefile | 4 +++-
> arch/Kconfig | 12
> config.mk| 6 +-
> 3 files changed, 20 insertions(+), 2 deletions(-)
> >>>
> >>> Can you provide a follow-up where this it clearer / easier to do
> >>> something than today? Thanks!
> >>
> >> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
> >> NXP code for the Management Complex is needed. I2C code either - this
> >> covers board/freescale/common/...
> >>
> >> Given you build machines from there with different SoCs under a
> >> new label - let's call it SuperLink, so you have
> >> * board/freescale/common
> >> * board/superlink/common
> >> * board/superlink/legacy-tune <-- based on some PowerPC
> >> * board/superlink/easy-tune <-- based on LS2088
> >> * board/superlink/heavy-tune <-- based on LX2160
> >>
> >> All *-tune machines the customer buys from SuperLink have a
> >> similar FPGA (there is a little bit more, but for the vision
> >> it's probably better to stay small) and a similar external
> >> PMIC/BMC.
> >>
> >> But SuperLink still uses code from board/freescale/common (their
> >> supplier) and it's not reasonable to copy those.
> >>
> >> I rate all this not suitable for a commit message. How do
> >> you suggest to proceed?
> >
> > Well, lets add in Michal as there are Zynq examples that could be
> > cleaned up with what you're proposing. Similarly, Vanessa and Otavio
> > might have thoughts here as they could rework some of the TechNexion
> > boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved
> > from board/ to some sub-directory?). Thanks all!
>
> I think it will be the best to take any of your example and simply
> create a series where this is applied to see if that code looks better
> then before. Applying this without usage doesn't make sense.
> >>>
> >>> I don't understand what you propose. Do you ask me to show internal
> >>> sources or the result of `find {...} -type f` or the content of our
> >>> Kconfig or defconfig?
> >>>
> >>> I'll try to do as much as I can (I'm sure, showing internal code won't
> >>> be permitted).
> >>>
> For zynq there are some boards like topic, bitmain, opalkelly which are
> staying in own folder but sourcing zynq board.c.
> >>>
> >>> As said, freescale common code stays in board/freescale/common/ - and
> >>> our code is in board/"superlink"/...
> >>
> >> I expect that you will find any example in the current code which can
> >> use this feature. It means you can enable this feature and any current
> >> configuration will really use it and will be regularly used/covered by
> >> testing.
> >> Adding feature which none will use in mainline should be IMHO nacked.
> >
> > Yes. All of the boards / people I added to the thread here have
> > platforms that would be able to leverage this idea, so I was hoping they
> > might have a perspective on if it would be clear than just:
> > obj-y += ../..//common/whatever.o
> > like is done today.
>
> So a PATCH-set with (likely non-working) examples will be fine or not?
No, but there are a number of existing configs that could be changed to
use the framework you're suggesting. So far it seems like the feedback
has been that maybe this would be cleaner than just what I said above,
but you need to convert some of them to use this, so we can see if it's
really cleaner or not.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
> Am 14.02.2020 um 14:45 schrieb Tom Rini :
>
> On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
>> On 14. 02. 20 12:37, Jens Rehsack wrote:
>>>
>>>
Am 14.02.2020 um 10:36 schrieb Michal Simek :
On 13. 02. 20 18:48, Tom Rini wrote:
> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
>>
>>
>>> Am 13.02.2020 um 16:01 schrieb Tom Rini :
>>>
>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
>>>
From: Jens Rehsack
Introduce SUPPLIER analogous to VENDOR to allow (from customer
perspective)
a VENDOR using it's SUPPLIER's common/ code.
This is reasonable, when a VENDOR (from customer perspective) builds
several machines sharing some features (e.g. some FPGA which has to be
initialized during u-boot) but wants to use common NXP or Samsung code
for the BSP instead of copying and create merge overhead.
Signed-off-by: Jens Rehsack
---
Makefile | 4 +++-
arch/Kconfig | 12
config.mk| 6 +-
3 files changed, 20 insertions(+), 2 deletions(-)
>>>
>>> Can you provide a follow-up where this it clearer / easier to do
>>> something than today? Thanks!
>>
>> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
>> NXP code for the Management Complex is needed. I2C code either - this
>> covers board/freescale/common/...
>>
>> Given you build machines from there with different SoCs under a
>> new label - let's call it SuperLink, so you have
>> * board/freescale/common
>> * board/superlink/common
>> * board/superlink/legacy-tune <-- based on some PowerPC
>> * board/superlink/easy-tune <-- based on LS2088
>> * board/superlink/heavy-tune <-- based on LX2160
>>
>> All *-tune machines the customer buys from SuperLink have a
>> similar FPGA (there is a little bit more, but for the vision
>> it's probably better to stay small) and a similar external
>> PMIC/BMC.
>>
>> But SuperLink still uses code from board/freescale/common (their
>> supplier) and it's not reasonable to copy those.
>>
>> I rate all this not suitable for a commit message. How do
>> you suggest to proceed?
>
> Well, lets add in Michal as there are Zynq examples that could be
> cleaned up with what you're proposing. Similarly, Vanessa and Otavio
> might have thoughts here as they could rework some of the TechNexion
> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved
> from board/ to some sub-directory?). Thanks all!
I think it will be the best to take any of your example and simply
create a series where this is applied to see if that code looks better
then before. Applying this without usage doesn't make sense.
>>>
>>> I don't understand what you propose. Do you ask me to show internal
>>> sources or the result of `find {...} -type f` or the content of our
>>> Kconfig or defconfig?
>>>
>>> I'll try to do as much as I can (I'm sure, showing internal code won't
>>> be permitted).
>>>
For zynq there are some boards like topic, bitmain, opalkelly which are
staying in own folder but sourcing zynq board.c.
>>>
>>> As said, freescale common code stays in board/freescale/common/ - and
>>> our code is in board/"superlink"/...
>>
>> I expect that you will find any example in the current code which can
>> use this feature. It means you can enable this feature and any current
>> configuration will really use it and will be regularly used/covered by
>> testing.
>> Adding feature which none will use in mainline should be IMHO nacked.
>
> Yes. All of the boards / people I added to the thread here have
> platforms that would be able to leverage this idea, so I was hoping they
> might have a perspective on if it would be clear than just:
> obj-y += ../..//common/whatever.o
> like is done today.
So a PATCH-set with (likely non-working) examples will be fine or not?
As you don't answer to my latest mail - I have no permission to publish
internal code.
Best regards
--
Jens Rehsack - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP
[U-Boot] [PATCH] defconfig: k2x_hs: Remove DTB_RESELECT to fix DHCP issue
From: Madan Srinivas This fixes the inadvertent definition of CONFIG_DTB_RESELECT and CONFIG_MULTI_DTB_FIT in the K2x HS defconfigs, that happened as part of a resync of the defconfigs. The inclusion of these config options causes ethernet to stop working on K2x HS devices as they interfere with the installation of the secure boot monitor. This patch also removes the above configs for the K2 GP devices, as they are not needed, and to keep the differences between the GP and HS defconfigs to a minimum. Signed-off-by: Madan Srinivas Signed-off-by: Andrew F. Davis --- configs/k2e_evm_defconfig | 2 -- configs/k2e_hs_evm_defconfig | 2 -- configs/k2hk_evm_defconfig| 2 -- configs/k2hk_hs_evm_defconfig | 2 -- configs/k2l_evm_defconfig | 2 -- 5 files changed, 10 deletions(-) diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig index 29334c4185..5df19efa9b 100644 --- a/configs/k2e_evm_defconfig +++ b/configs/k2e_evm_defconfig @@ -37,8 +37,6 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=davinci_nand.0:1024k(bootloader)ro,512k(params CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="keystone-k2e-evm" -CONFIG_DTB_RESELECT=y -CONFIG_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_NAND=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig index 87050ef489..d4b5a5fddd 100644 --- a/configs/k2e_hs_evm_defconfig +++ b/configs/k2e_hs_evm_defconfig @@ -29,8 +29,6 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=davinci_nand.0:1024k(bootloader)ro,512k(params CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="keystone-k2e-evm" -CONFIG_DTB_RESELECT=y -CONFIG_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_NAND=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/configs/k2hk_evm_defconfig b/configs/k2hk_evm_defconfig index 4cd8647d0f..0635f4a976 100644 --- a/configs/k2hk_evm_defconfig +++ b/configs/k2hk_evm_defconfig @@ -37,8 +37,6 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=davinci_nand.0:1024k(bootloader)ro,512k(params CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="keystone-k2hk-evm" -CONFIG_DTB_RESELECT=y -CONFIG_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_NAND=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/configs/k2hk_hs_evm_defconfig b/configs/k2hk_hs_evm_defconfig index bd60aa86a3..96cab51687 100644 --- a/configs/k2hk_hs_evm_defconfig +++ b/configs/k2hk_hs_evm_defconfig @@ -29,8 +29,6 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=davinci_nand.0:1024k(bootloader)ro,512k(params CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="keystone-k2hk-evm" -CONFIG_DTB_RESELECT=y -CONFIG_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_NAND=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/configs/k2l_evm_defconfig b/configs/k2l_evm_defconfig index b564b23dca..66f778fa0b 100644 --- a/configs/k2l_evm_defconfig +++ b/configs/k2l_evm_defconfig @@ -37,8 +37,6 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=davinci_nand.0:1024k(bootloader)ro,512k(params CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="keystone-k2l-evm" -CONFIG_DTB_RESELECT=y -CONFIG_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_NAND=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y -- 2.17.1
Re: i.MX8QXP MEK does not boot
Hi Anatolij, On Fri, Feb 14, 2020 at 7:25 AM Anatolij Gustschin wrote: > We have two issues here, power domain off hang reported here [1] > and disabling nodes in device tree since commit 9f779fa4105f. If I try reverting these two commits the kernel starts booting: http://code.bulix.org/0xmech-1126740 but it stops when the LPUART is probed. Peng/Ye Li, Could you guys please take a look? Not being able to boot a kernel on i.mx8qxp mek makes U-Boot not very useful :-) Thanks
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
> On 14. 02. 20 12:37, Jens Rehsack wrote:
> >
> >
> >> Am 14.02.2020 um 10:36 schrieb Michal Simek :
> >>
> >> On 13. 02. 20 18:48, Tom Rini wrote:
> >>> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
>
>
> > Am 13.02.2020 um 16:01 schrieb Tom Rini :
> >
> > On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
> >
> >> From: Jens Rehsack
> >>
> >> Introduce SUPPLIER analogous to VENDOR to allow (from customer
> >> perspective)
> >> a VENDOR using it's SUPPLIER's common/ code.
> >>
> >> This is reasonable, when a VENDOR (from customer perspective) builds
> >> several machines sharing some features (e.g. some FPGA which has to be
> >> initialized during u-boot) but wants to use common NXP or Samsung code
> >> for the BSP instead of copying and create merge overhead.
> >>
> >> Signed-off-by: Jens Rehsack
> >> ---
> >> Makefile | 4 +++-
> >> arch/Kconfig | 12
> >> config.mk| 6 +-
> >> 3 files changed, 20 insertions(+), 2 deletions(-)
> >
> > Can you provide a follow-up where this it clearer / easier to do
> > something than today? Thanks!
>
> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
> NXP code for the Management Complex is needed. I2C code either - this
> covers board/freescale/common/...
>
> Given you build machines from there with different SoCs under a
> new label - let's call it SuperLink, so you have
> * board/freescale/common
> * board/superlink/common
> * board/superlink/legacy-tune <-- based on some PowerPC
> * board/superlink/easy-tune <-- based on LS2088
> * board/superlink/heavy-tune <-- based on LX2160
>
> All *-tune machines the customer buys from SuperLink have a
> similar FPGA (there is a little bit more, but for the vision
> it's probably better to stay small) and a similar external
> PMIC/BMC.
>
> But SuperLink still uses code from board/freescale/common (their
> supplier) and it's not reasonable to copy those.
>
> I rate all this not suitable for a commit message. How do
> you suggest to proceed?
> >>>
> >>> Well, lets add in Michal as there are Zynq examples that could be
> >>> cleaned up with what you're proposing. Similarly, Vanessa and Otavio
> >>> might have thoughts here as they could rework some of the TechNexion
> >>> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved
> >>> from board/ to some sub-directory?). Thanks all!
> >>
> >> I think it will be the best to take any of your example and simply
> >> create a series where this is applied to see if that code looks better
> >> then before. Applying this without usage doesn't make sense.
> >
> > I don't understand what you propose. Do you ask me to show internal
> > sources or the result of `find {...} -type f` or the content of our
> > Kconfig or defconfig?
> >
> > I'll try to do as much as I can (I'm sure, showing internal code won't
> > be permitted).
> >
> >> For zynq there are some boards like topic, bitmain, opalkelly which are
> >> staying in own folder but sourcing zynq board.c.
> >
> > As said, freescale common code stays in board/freescale/common/ - and
> > our code is in board/"superlink"/...
>
> I expect that you will find any example in the current code which can
> use this feature. It means you can enable this feature and any current
> configuration will really use it and will be regularly used/covered by
> testing.
> Adding feature which none will use in mainline should be IMHO nacked.
Yes. All of the boards / people I added to the thread here have
platforms that would be able to leverage this idea, so I was hoping they
might have a perspective on if it would be clear than just:
obj-y += ../..//common/whatever.o
like is done today.
--
Tom
signature.asc
Description: PGP signature
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Atish Patra [mailto:ati...@atishpatra.org] > Sent: Friday, February 14, 2020 7:57 AM > To: Ard Biesheuvel > Cc: Chang, Abner (HPS SW/FW Technologist) ; > Heinrich Schuchardt ; Alexander Graf > ; U-Boot Mailing List ; Atish Patra > ; l...@nuviainc.com > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > On Thu, Feb 13, 2020 at 2:11 PM Ard Biesheuvel > wrote: > > > > On Thu, 13 Feb 2020 at 19:59, Atish Patra wrote: > > > > > > On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel > > > wrote: > > > > > > > > On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW > > > > Technologist) wrote: > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > > > > > > Sent: Wednesday, February 12, 2020 2:26 AM > > > > > > To: Chang, Abner (HPS SW/FW Technologist) > > > > > > ; Atish Patra ; > > > > > > Ard Biesheuvel > > > > > > Cc: Alexander Graf ; U-Boot Mailing List > > > > > b...@lists.denx.de>; Atish Patra ; > > > > > > l...@nuviainc.com > > > > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific > > > > > > UEFI setup > > > > > > > > > > > > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > > > > > > > > > > > > > > > > >> -Original Message- > > > > > > >> From: Atish Patra [mailto:ati...@atishpatra.org] > > > > > > >> Sent: Friday, February 7, 2020 6:56 AM > > > > > > >> To: Ard Biesheuvel ; Chang, > > > > > > >> Abner (HPS SW/FW > > > > > > >> Technologist) > > > > > > >> Cc: Alexander Graf ; Heinrich Schuchardt > > > > > > >> ; U-Boot Mailing List > > > > > > >> ; Atish Patra ; > > > > > > >> l...@nuviainc.com > > > > > > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture > > > > > > >> specific UEFI setup > > > > > > >> > > > > > > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > > > > > > >> > > > > > > >> wrote: > > > > > > >>> > > > > > > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra > wrote: > > > > > > > > > > > > On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On 06.02.20 19:28, Atish Patra wrote: > > > > > > >> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > > > > > > >> wrote: > > > > > > >>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > > > > > > >> wrote: > > > > > > RISC-V booting currently is based on a per boot stage > > > > > > lottery to determine the active CPU. The Hart State > > > > > > Management (HSM) SBI extension replaces this lottery > > > > > > by using a dedicated primary > > > > > > >> CPU. > > > > > > > > > > > > Cf. Hart State Management Extension, Extension ID: > > > > > > 0x48534D > > > > > > (HSM) > > > > > > https://github.com/riscv/riscv-sbi-doc/blob/master/ri > > > > > > scv-sbi.a > > > > > > doc > > > > > > > > > > > > In this scenario the id of the active hart has to be > > > > > > passed from boot stage to boot stage. Using a UEFI > > > > > > variable would provide > > > > > > >> an easy implementation. > > > > > > > > > > > > This patch provides a weak function that is called at > > > > > > the end of the setup of U-Boot's UEFI sub-system. By > > > > > > overriding this function architecture specific UEFI > > > > > > variables or configuration tables > > > > > > >> can be created. > > > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > > > > > > > > Reviewed-by: Atish Patra > > > > > > >>> OK, so I have a couple of questions: > > > > > > >>> > > > > > > >>> - does RISC-V use device tree? if so, why are you not > > > > > > >>> passing the active hart via a property in the /chosen node? > > > > > > >> Yes. RISC-V uses device tree. Technically, we can pass > > > > > > >> the active hart by a DT property but that means we have > > > > > > >> to modify the DT in OpenSBI (RISC-V specific run time > service provider). > > > > > > >> We have been trying to avoid that if possible so that > > > > > > >> DT is not bounced around. This also limits U-Boot to > > > > > > >> have its own device tree. > > > > > > > > > > > > > > > > > > > > > I don't understand how this is different from the UEFI > > > > > > > variable scheme proposed here? If you want to create an > > > > > > > SBI interface to propagate the active HART that U-Boot > > > > > > > then uses to populate the /chosen property, that's probably > fine as well. > > > > > > > > > > > > > > > > > > > We don't want to create SBI interface to pass this information. > > > > > > > > > > > > > We already have hooks that allow you to modify the DT > > > > > > > right before it gets delivered to the
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
> Am 14.02.2020 um 13:08 schrieb Fabio Estevam : > > On Fri, Feb 14, 2020 at 6:36 AM Michal Simek wrote: > >> I think it will be the best to take any of your example and simply >> create a series where this is applied to see if that code looks better >> then before. Applying this without usage doesn't make sense. > > Agreed. > > SYS_SUPPLIER is introduced in this patch, but there is currently no user. The intent is to introduce it since it is missing for described use case. I do not intend to review any BSP whether it can make benefits of this. I'm fine to keep the usage intern only when it's unwanted. I agree to submit an example - created especially for demonstration purposes without any code in it. When this is enough, please tell me. Best regards -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
> Am 14.02.2020 um 10:36 schrieb Michal Simek :
>
> On 13. 02. 20 18:48, Tom Rini wrote:
>> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
>>>
>>>
Am 13.02.2020 um 16:01 schrieb Tom Rini :
On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
> From: Jens Rehsack
>
> Introduce SUPPLIER analogous to VENDOR to allow (from customer
> perspective)
> a VENDOR using it's SUPPLIER's common/ code.
>
> This is reasonable, when a VENDOR (from customer perspective) builds
> several machines sharing some features (e.g. some FPGA which has to be
> initialized during u-boot) but wants to use common NXP or Samsung code
> for the BSP instead of copying and create merge overhead.
>
> Signed-off-by: Jens Rehsack
> ---
> Makefile | 4 +++-
> arch/Kconfig | 12
> config.mk| 6 +-
> 3 files changed, 20 insertions(+), 2 deletions(-)
Can you provide a follow-up where this it clearer / easier to do
something than today? Thanks!
>>>
>>> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
>>> NXP code for the Management Complex is needed. I2C code either - this
>>> covers board/freescale/common/...
>>>
>>> Given you build machines from there with different SoCs under a
>>> new label - let's call it SuperLink, so you have
>>> * board/freescale/common
>>> * board/superlink/common
>>> * board/superlink/legacy-tune <-- based on some PowerPC
>>> * board/superlink/easy-tune <-- based on LS2088
>>> * board/superlink/heavy-tune <-- based on LX2160
>>>
>>> All *-tune machines the customer buys from SuperLink have a
>>> similar FPGA (there is a little bit more, but for the vision
>>> it's probably better to stay small) and a similar external
>>> PMIC/BMC.
>>>
>>> But SuperLink still uses code from board/freescale/common (their
>>> supplier) and it's not reasonable to copy those.
>>>
>>> I rate all this not suitable for a commit message. How do
>>> you suggest to proceed?
>>
>> Well, lets add in Michal as there are Zynq examples that could be
>> cleaned up with what you're proposing. Similarly, Vanessa and Otavio
>> might have thoughts here as they could rework some of the TechNexion
>> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved
>> from board/ to some sub-directory?). Thanks all!
>
> I think it will be the best to take any of your example and simply
> create a series where this is applied to see if that code looks better
> then before. Applying this without usage doesn't make sense.
I don't understand what you propose. Do you ask me to show internal
sources or the result of `find {...} -type f` or the content of our
Kconfig or defconfig?
I'll try to do as much as I can (I'm sure, showing internal code won't
be permitted).
> For zynq there are some boards like topic, bitmain, opalkelly which are
> staying in own folder but sourcing zynq board.c.
As said, freescale common code stays in board/freescale/common/ - and
our code is in board/"superlink"/...
Best regards
--
Jens Rehsack - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, February 14, 2020 8:07 PM > To: Chang, Abner (HPS SW/FW Technologist) > Cc: Alexander Graf ; Atish Patra ; > Heinrich Schuchardt ; U-Boot Mailing List b...@lists.denx.de>; Atish Patra ; > l...@nuviainc.com > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > On Fri, 14 Feb 2020 at 13:04, Chang, Abner (HPS SW/FW Technologist) > wrote: > > > > > > > > > -Original Message- > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > Sent: Friday, February 14, 2020 7:33 PM > > > To: Chang, Abner (HPS SW/FW Technologist) > > > Cc: Alexander Graf ; Atish Patra > > > ; Heinrich Schuchardt ; > > > U-Boot Mailing List ; Atish Patra > > > ; l...@nuviainc.com > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI > > > setup > > > > > > On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist) > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Alexander Graf [mailto:ag...@csgraf.de] > > > > > Sent: Friday, February 14, 2020 4:07 PM > > > > > To: Chang, Abner (HPS SW/FW Technologist) > > > > > > Cc: Atish Patra ; Ard Biesheuvel > > > > > ; Heinrich Schuchardt > > > > > ; U-Boot Mailing List > > > > > ; Atish Patra ; > > > > > l...@nuviainc.com > > > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific > > > > > UEFI setup > > > > > > > > > > > > > > > > > > > > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW > > > > > > Technologist) > > > > > : > > > > > > > > > > > > ... > > > > > The table from this link https://github.com/riscv/riscv- > > > > > smbios/blob/master/RISCV-SMBIOS.md > > > > > > Offset 3 is HART ID, and offset 13h is the boolean indicates > > > > > > this hart is the > > > > > boot hart. > > > > > > > > > > > >> kernel. How difficult is to modify the DT in EDK2 ? > > > > > >> > > > > > > I never used DT before on PC/Server project. However, the DT > > > > > > code is over > > > > > there in edk2 repo which mostly used by ARM platforms. I don’t > > > > > think it is difficult to adopt it though. > > > > > > > > > > Yes, some arm platforms already transform the DT just fine. > > > > > Let's really please not use SMBIOS for anything boot or system > > > > > configuration related: its purpose is in general purely informational. > > > > As DT to embedded system, SMBIOS provides system > > > information/configuration on most PC/Server platforms. Especially to > > > pre-OS applications such as EFI diagnostic tool, factory/customer > > > deployment tools, pre-OS system configuration, network boot image > > > and EFI OS boot loader as well. The intention of RISC-V SMBIOS is > > > support above applications using single image for the RISC-V core > > > variants, Non ACPI-aware OS is also part of this scope, but it is rare > though. > > > > If you are booting to OS which is actually well understand DT then > > > > just use > > > DT, but for PC/Server industry, SMBIOS would be still our choice before > OS. > > > > We may have to define the corresponding syntax If DT doesn't have > > > > it for > > > boot HART information. RISC-V System Description Task Group (f it > > > formed) would be a good place to bring this topic. > > > > Maybe you can support both DT or SMBIOS to retrieve the > > > > information you > > > need on demand... > > > > > > > > > > SMBIOS is an informational protocol. Firmware or OS loaders should > > > not rely on it for low-level things like the hart id. > > Hart ID is just one of the information in type 44 which is the same as the > processor information provided in type 4. > > > > Fine. But that doesn't mean we should be parsing SMBIOS tables in the Linux > startup code. Ok, this is not my familiar area. You guys are better than me. > > > > > > > > > > > > > > So yes, unless I hear really good arguments against passing it > > > > > via /chosen in DT, I'd strongly prefer that mechanism. For ACPI > > > > > (if it ever happens), there would be a special ACPI table for it > > > > > anyway. > > > > Yes, we do have an ECR for ACPI spec to report the RISC-V core > > > characteristic which is similar to what we done for SMBIOS. > > > > > > > > > > So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and > > > we'll always have to parse two sets of tables, just to discover the > > > hart id. I don't think that makes sense at all, to be honest. > > As I said, SMBIOS is mostly for pre OS applications, Type 42 is a good > example, the Host interface used to talk to BMC and Redfish service in pre- > OS environment (also runtime OS). > > For OS boot, maybe OS (like Windows) still retrieves information from it > before ACPI enable. > > > > I have no preference of using which way to get boot hard ID for the > > boot process, either to get it from DT, SMBIOS or ACPI seems to me > > the same... just the information is provided over there > > > > > > > >
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Alexander Graf [mailto:ag...@csgraf.de] > Sent: Friday, February 14, 2020 4:07 PM > To: Chang, Abner (HPS SW/FW Technologist) > Cc: Atish Patra ; Ard Biesheuvel > ; Heinrich Schuchardt ; > U-Boot Mailing List ; Atish Patra > ; l...@nuviainc.com > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > > > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW Technologist) > : > > > > > > > >> -Original Message- > >> From: Atish Patra [mailto:ati...@atishpatra.org] > >> Sent: Friday, February 14, 2020 7:57 AM > >> To: Ard Biesheuvel > >> Cc: Chang, Abner (HPS SW/FW Technologist) ; > >> Heinrich Schuchardt ; Alexander Graf > >> ; U-Boot Mailing List ; Atish > Patra > >> ; l...@nuviainc.com > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > >> > >>> On Thu, Feb 13, 2020 at 2:11 PM Ard Biesheuvel > > >>> wrote: > >>> > >>> On Thu, 13 Feb 2020 at 19:59, Atish Patra wrote: > > On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel > wrote: > > > > On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW > > Technologist) wrote: > >> > >> > >> > >>> -Original Message- > >>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > >>> Sent: Wednesday, February 12, 2020 2:26 AM > >>> To: Chang, Abner (HPS SW/FW Technologist) > >>> ; Atish Patra ; > >>> Ard Biesheuvel > >>> Cc: Alexander Graf ; U-Boot Mailing List >>> b...@lists.denx.de>; Atish Patra ; > >>> l...@nuviainc.com > >>> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific > >>> UEFI setup > >>> > >>> On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > -Original Message- > > From: Atish Patra [mailto:ati...@atishpatra.org] > > Sent: Friday, February 7, 2020 6:56 AM > > To: Ard Biesheuvel ; Chang, > > Abner (HPS SW/FW > > Technologist) > > Cc: Alexander Graf ; Heinrich Schuchardt > > ; U-Boot Mailing List > > ; Atish Patra ; > > l...@nuviainc.com > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture > > specific UEFI setup > > > > On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > > > > wrote: > >> > >> On Thu, 6 Feb 2020 at 21:06, Atish Patra > >> wrote: > >>> > >>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf > >>> > >>> wrote: > > > On 06.02.20 19:28, Atish Patra wrote: > > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > > wrote: > >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > > wrote: > >>> RISC-V booting currently is based on a per boot stage > >>> lottery to determine the active CPU. The Hart State > >>> Management (HSM) SBI extension replaces this lottery > >>> by using a dedicated primary > > CPU. > >>> > >>> Cf. Hart State Management Extension, Extension ID: > >>> 0x48534D > >>> (HSM) > >>> https://github.com/riscv/riscv-sbi-doc/blob/master/ri > >>> scv-sbi.a > >>> doc > >>> > >>> In this scenario the id of the active hart has to be > >>> passed from boot stage to boot stage. Using a UEFI > >>> variable would provide > > an easy implementation. > >>> > >>> This patch provides a weak function that is called at > >>> the end of the setup of U-Boot's UEFI sub-system. By > >>> overriding this function architecture specific UEFI > >>> variables or configuration tables > > can be created. > >>> > >>> Signed-off-by: Heinrich Schuchardt > >>> > >>> Reviewed-by: Atish Patra > >> OK, so I have a couple of questions: > >> > >> - does RISC-V use device tree? if so, why are you not > >> passing the active hart via a property in the /chosen node? > > Yes. RISC-V uses device tree. Technically, we can pass > > the active hart by a DT property but that means we have > > to modify the DT in OpenSBI (RISC-V specific run time > >> service provider). > > We have been trying to avoid that if possible so that > > DT is not bounced around. This also limits U-Boot to > > have its own device tree. > > > I don't understand how this is different from the UEFI > variable scheme proposed here? If you want to create an > SBI interface to propagate the active HART that U-Boot > then uses to populate the /chosen property, that's probably > >> fine as well. >
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, February 14, 2020 7:33 PM > To: Chang, Abner (HPS SW/FW Technologist) > Cc: Alexander Graf ; Atish Patra ; > Heinrich Schuchardt ; U-Boot Mailing List b...@lists.denx.de>; Atish Patra ; > l...@nuviainc.com > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist) > wrote: > > > > > > > > > -Original Message- > > > From: Alexander Graf [mailto:ag...@csgraf.de] > > > Sent: Friday, February 14, 2020 4:07 PM > > > To: Chang, Abner (HPS SW/FW Technologist) > > > Cc: Atish Patra ; Ard Biesheuvel > > > ; Heinrich Schuchardt > > > ; U-Boot Mailing List ; > > > Atish Patra ; l...@nuviainc.com > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI > > > setup > > > > > > > > > > > > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW > > > > Technologist) > > > : > > > > > > ... > > > The table from this link https://github.com/riscv/riscv- > > > smbios/blob/master/RISCV-SMBIOS.md > > > > Offset 3 is HART ID, and offset 13h is the boolean indicates this > > > > hart is the > > > boot hart. > > > > > > > >> kernel. How difficult is to modify the DT in EDK2 ? > > > >> > > > > I never used DT before on PC/Server project. However, the DT code > > > > is over > > > there in edk2 repo which mostly used by ARM platforms. I don’t think > > > it is difficult to adopt it though. > > > > > > Yes, some arm platforms already transform the DT just fine. Let's > > > really please not use SMBIOS for anything boot or system > > > configuration related: its purpose is in general purely informational. > > As DT to embedded system, SMBIOS provides system > information/configuration on most PC/Server platforms. Especially to pre-OS > applications such as EFI diagnostic tool, factory/customer deployment tools, > pre-OS system configuration, network boot image and EFI OS boot loader as > well. The intention of RISC-V SMBIOS is support above applications using > single image for the RISC-V core variants, Non ACPI-aware OS is also part of > this scope, but it is rare though. > > If you are booting to OS which is actually well understand DT then just use > DT, but for PC/Server industry, SMBIOS would be still our choice before OS. > > We may have to define the corresponding syntax If DT doesn't have it for > boot HART information. RISC-V System Description Task Group (f it formed) > would be a good place to bring this topic. > > Maybe you can support both DT or SMBIOS to retrieve the information you > need on demand... > > > > SMBIOS is an informational protocol. Firmware or OS loaders should not rely > on it for low-level things like the hart id. Hart ID is just one of the information in type 44 which is the same as the processor information provided in type 4. > > > > > > > So yes, unless I hear really good arguments against passing it via > > > /chosen in DT, I'd strongly prefer that mechanism. For ACPI (if it > > > ever happens), there would be a special ACPI table for it anyway. > > Yes, we do have an ECR for ACPI spec to report the RISC-V core > characteristic which is similar to what we done for SMBIOS. > > > > So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and we'll > always have to parse two sets of tables, just to discover the hart id. I don't > think that makes sense at all, to be honest. As I said, SMBIOS is mostly for pre OS applications, Type 42 is a good example, the Host interface used to talk to BMC and Redfish service in pre-OS environment (also runtime OS). For OS boot, maybe OS (like Windows) still retrieves information from it before ACPI enable. I have no preference of using which way to get boot hard ID for the boot process, either to get it from DT, SMBIOS or ACPI seems to me the same... just the information is provided over there > > SMBIOS is wonderful for the sysadmin to look at the model numbers of the > installed DIMMs etc. But for core boot stuff, we really should avoid it. Security consideration?
RE: [PATCH v3 0/5] usb: host: dwc2: use driver model for PHY and CLOCK
Hi,
> From: Patrick DELAUNAY
> Sent: mardi 12 novembre 2019 10:42
> To: u-boot@lists.denx.de
> Cc: ley.foon@intel.com; b.galv...@gmail.com;
> simon.k.r.goldschm...@gmail.com; Patrick DELAUNAY
> ; Jagan Teki ; Jean-
> Jacques Hiblot ; Lokesh Vutla ; Lukasz
> Majewski ; Marek Vasut ; Michal Suchanek
> ; Peng Fan ; Sekhar Nori
> ; Simon Glass ; Sven Schwermer
> ; U-Boot STM32 mailman.stormreply.com>
> Subject: [PATCH v3 0/5] usb: host: dwc2: use driver model for PHY and CLOCK
> Importance: High
>
>
> In this serie I update the DWC2 host driver to use the device tree
> information and
> the associated PHY and CLOCK drivers when they are available.
>
> CI-Travis build is OK for all target after V3:
> https://travis-ci.org/patrickdelaunay/u-boot/builds/609496187
>
> In V2, I cause the warnings for some boards:
> drivers/usb/host/built-in.o: In function `dwc2_usb_remove':
> drivers/usb/host/dwc2.c:1441: undefined reference to `clk_disable_bulk'
>
> I test this serie on stm32mp157c-ev1 board, with PHY and CLK support
>
> The U-CLASS are provided by:
> - PHY by USBPHYC driver = ./drivers/phy/phy-stm32-usbphyc.c
> - CLOCK by RCC clock driver = drivers/clk/clk_stm32mp1.c
> - RESET by RCC reset driver = drivers/reset/stm32-reset.c
>
> And I activate the configuration
> +CONFIG_USB_DWC2=y
>
> PS: it is not the default configuration to avoid conflict with gadget
> driver
>
> To solve a binding issue, I also deactivate the gadget support:
> by default only one driver is bound to theusbotg_hs node with "snps,dwc2"
> compatible, and today it is the device one (the first in the driver list).
>
> I also need to deactivate hnp-srp support with:
>
> _hs {
> /* need to disable ONLY for HOST support */
> hnp-srp-disable;
> };
>
> WARNING: OTG with device or host support is not correctly handle by DWC2
> driver (see example for dynamic OTG role in DWC3 driver).
>
> The tests executed on the stm32mp157c-ev1 target:
>
> STM32MP> usb start
> starting USB...
> Bus usb-otg@4900: USB DWC2
> Bus usbh-ehci@5800d000: USB EHCI 1.00
> scanning bus usb-otg@4900 for devices... 2 USB Device(s) found scanning
> bus usbh-ehci@5800d000 for devices... 3 USB Device(s) found
>scanning usb for storage devices... 2 Storage Device(s) found
> STM32MP> usb tree
> USB device tree:
> 1 Hub (480 Mb/s, 0mA)
> | U-Boot Root Hub
> |
> +-2 Mass Storage (480 Mb/s, 300mA)
>Verbatim STORE N GO 070731C8ACD7EE97
>
> 1 Hub (480 Mb/s, 0mA)
> | u-boot EHCI Host Controller
> |
> +-2 Hub (480 Mb/s, 2mA)
> |
> +-3 Mass Storage (480 Mb/s, 500mA)
> Generic USB Storage
>
> STM32MP> ls usb 0
>4096 .
>4096 ..
> 16384 lost+found
>4096 record
> 1490212 xipImage
> 21058006 vmlinux
>
> STM32MP> load usb 0 0xC000 vmlinux
> 21058006 bytes read in 10851 ms (1.9 MiB/s)
>
>
> Changes in v3:
> - Add stub for clk_disable_bulk
>
> Changes in v2:
> - update dev_err
> - update commit message
> - change dev_err to dev_dbg for PHY function call
> - treat dwc2_shutdown_phy error
> - add clk_disable_bulk in dwc2_usb_remove
>
> Patrick Delaunay (5):
> dm: clk: add stub for clk_disable_bulk when CONFIG_CLK is desactivated
> usb: host: dwc2: add phy support
> usb: host: dwc2: add clk support
> usb: host: dwc2: force reset assert
> usb: host: dwc2: add trace to have clean usb start
>
> drivers/usb/host/dwc2.c | 100
> +++-
> include/clk.h | 4 ++
> 2 files changed, 103 insertions(+), 1 deletion(-)
>
> --
> 2.17.1
Any comments on this serie or I need to rebase it and resend the serie ?
http://patchwork.ozlabs.org/project/uboot/list/?series=142257
Sorry for the delay...
I miss the previous merge windows for v2020.01 and now I think it also the case
for v2020.04 !
The previous version v2 was almost ready
http://patchwork.ozlabs.org/project/uboot/list/?series=141678=*
In v3 I only solve the compilation issue on some board with patch 1/5
(= http://patchwork.ozlabs.org/patch/1193397/)
PS: for other remarks I create a separate serie:
http://patchwork.ozlabs.org/project/uboot/list/?series=142260
Regards
Patrick
Re: [PATCH v1 2/2] ARM: dts: imx8mm-verdin: drop rgmii_rxc_dly/txc_dly
On Fri, Feb 14, 2020 at 2:37 PM Igor Opaniuk wrote:
>
> From: Max Krummenacher
>
> The FEC in the i.MX8MM doesn't support this feature. So don't pretend one
> can use it.
>
> Signed-off-by: Max Krummenacher
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/dts/imx8mm-verdin.dts | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
> index 2980053e82..b86f46e03e 100644
> --- a/arch/arm/dts/imx8mm-verdin.dts
> +++ b/arch/arm/dts/imx8mm-verdin.dts
> @@ -153,8 +153,6 @@
>
> {
> fsl,magic-packet;
> - fsl,rgmii_rxc_dly;
> - fsl,rgmii_txc_dly;
> phy-handle = <>;
> phy-mode = "rgmii";
> phy-supply = <_ethphy>;
> --
> 2.17.1
>
--
Best regards
Oleksandr Suvorov
Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
4800 (main line)
Re: [PATCH v1 1/2] ARM: dts: imx8mm-verdin: dm-spl for pinctrl_usdhc1 node
On Fri, Feb 14, 2020 at 2:36 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Let pinctrl configuration for eMMC node (usdhc1) also be
> accessible in SPL.
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> index d091577a96..e60b9faee4 100644
> --- a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> @@ -69,6 +69,10 @@
> u-boot,dm-spl;
> };
>
> +_usdhc1 {
> + u-boot,dm-spl;
> +};
> +
> _usdhc2 {
> u-boot,dm-spl;
> };
> --
> 2.17.1
>
--
Best regards
Oleksandr Suvorov
Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
4800 (main line)
RPI4: fail too boot with an initrd
Hello Since the inclusion of the "enable network support in RPi4 config" serie on uboot, I have started to work on adding the rpi4 in kernelCI. But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp. Using booti I hit: [0.00] Linux version 5.6.0-rc1-next-20200212 (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (LinaroGCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020 [0.00] Machine model: Raspberry Pi 4 Model B [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '') [0.00] printk: bootconsole [uart0] enabled [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] OF: reserved mem: failed to allocate memory for node 'linux,cma' [0.00] cma: Failed to reserve 32 MiB [0.00] Kernel panic - not syncing: Failed to allocate page table page [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc1-next-20200212 #66 [0.00] Hardware name: Raspberry Pi 4 Model B (DT) [0.00] Call trace: [0.00] dump_backtrace+0x0/0x1a0 [0.00] show_stack+0x14/0x20 [0.00] dump_stack+0xbc/0x104 [0.00] panic+0x16c/0x37c [0.00] early_pgtable_alloc+0x30/0xa0 [0.00] __create_pgd_mapping+0x36c/0x588 [0.00] map_kernel_segment+0x70/0xa4 [0.00] paging_init+0xf4/0x528 [0.00] setup_arch+0x250/0x5d8 [0.00] start_kernel+0x90/0x6d8 Since the same kernel boot with bootefi and that bootefi lack ramdisk address, I tried to add the address in the dtb via: fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 0x0008 0x0240 But with that, I get: initrd not fully accessible via the linear mapping -- please check your bootloader ... I have tried many different start/end address without any change. My last resort was to embed the rootfs in the kernel. But with the correct console=, the boot stop at: [1.373557] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 16, base_baud = 0) is a PL011 rev2 [1.382565] printk: console [ttyAMA0] enabled [1.391318] printk: bootconsole [uart0] disabled With the wrong console (ttyS0), the boot go up to start init which panic due to lack of console. Regards
RE: [PATCH v1 1/2] ARM: dts: imx8mm-verdin: dm-spl for pinctrl_usdhc1 node
> Subject: [PATCH v1 1/2] ARM: dts: imx8mm-verdin: dm-spl for pinctrl_usdhc1
> node
>
> From: Igor Opaniuk
>
> Let pinctrl configuration for eMMC node (usdhc1) also be accessible in SPL.
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Peng Fan
> ---
>
> arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> index d091577a96..e60b9faee4 100644
> --- a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> @@ -69,6 +69,10 @@
> u-boot,dm-spl;
> };
>
> +_usdhc1 {
> + u-boot,dm-spl;
> +};
> +
> _usdhc2 {
> u-boot,dm-spl;
> };
> --
> 2.17.1
RE: [PATCH v1 2/2] ARM: dts: imx8mm-verdin: drop rgmii_rxc_dly/txc_dly
> Subject: [PATCH v1 2/2] ARM: dts: imx8mm-verdin: drop
> rgmii_rxc_dly/txc_dly
>
> From: Max Krummenacher
>
> The FEC in the i.MX8MM doesn't support this feature. So don't pretend one
> can use it.
>
> Signed-off-by: Max Krummenacher
> Signed-off-by: Igor Opaniuk
Acked-by: Peng Fan
> ---
>
> arch/arm/dts/imx8mm-verdin.dts | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm-verdin.dts
> b/arch/arm/dts/imx8mm-verdin.dts index 2980053e82..b86f46e03e 100644
> --- a/arch/arm/dts/imx8mm-verdin.dts
> +++ b/arch/arm/dts/imx8mm-verdin.dts
> @@ -153,8 +153,6 @@
>
> {
> fsl,magic-packet;
> - fsl,rgmii_rxc_dly;
> - fsl,rgmii_txc_dly;
> phy-handle = <>;
> phy-mode = "rgmii";
> phy-supply = <_ethphy>;
> --
> 2.17.1
RE: [PATCH] stm32mp1: remove fdt_high and initrd_high in environment
Hi, > From: Patrick DELAUNAY > Sent: lundi 10 février 2020 11:54 > > Remove fdt_high and initrd_high (set to 0x) in stm32mp1 board > enviromnent, > and U-Boot always relocate FDT and initrd in bootm command. > > This relocation is limited by CONFIG_SYS_BOOTMAPSZ which indicates the size > of the memory region where it is safe to place data passed to the Linux kernel > (DTB, initrd), it is > a) Less than or equal to RAM size. > b) not within the kernel's highmem region > > So 256M seems large enough in most circumstances and users can override this > value via environment variable "bootm_mapsize" > if needed. > > This modification increases the boot time but avoid assumption on aligned > address for bootm command. > > A user can still define this variables themselves if the FDT or initrd is > either left in- > place or copied to a specific location. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
[PATCH v1 1/2] ARM: dts: imx8mm-verdin: dm-spl for pinctrl_usdhc1 node
From: Igor Opaniuk
Let pinctrl configuration for eMMC node (usdhc1) also be
accessible in SPL.
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
index d091577a96..e60b9faee4 100644
--- a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
@@ -69,6 +69,10 @@
u-boot,dm-spl;
};
+_usdhc1 {
+ u-boot,dm-spl;
+};
+
_usdhc2 {
u-boot,dm-spl;
};
--
2.17.1
[PATCH v1 2/2] ARM: dts: imx8mm-verdin: drop rgmii_rxc_dly/txc_dly
From: Max Krummenacher
The FEC in the i.MX8MM doesn't support this feature. So don't pretend one
can use it.
Signed-off-by: Max Krummenacher
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx8mm-verdin.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
index 2980053e82..b86f46e03e 100644
--- a/arch/arm/dts/imx8mm-verdin.dts
+++ b/arch/arm/dts/imx8mm-verdin.dts
@@ -153,8 +153,6 @@
{
fsl,magic-packet;
- fsl,rgmii_rxc_dly;
- fsl,rgmii_txc_dly;
phy-handle = <>;
phy-mode = "rgmii";
phy-supply = <_ethphy>;
--
2.17.1
Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"
Hi,
I chose to implement boot count / selection functionality as a command instead:
https://patchwork.ozlabs.org/patch/943549/
I do plan to extend it a bit in the coming weeks though:
* move the env-get and -set to weak functions, so that board files can put the
info wherever.
* add support for multiple lists of boot slots, so that the kernel can be
updated independently of the rootfs.
// Martin
On 14 February 2020 12.54.35 CET, Rasmus Villemoes
wrote:
>On 13/02/2020 16.55, Wolfgang Denk wrote:
>> Dear Rasmus,
>>
>> In message you
>wrote:
>>>
>>> I'm sorry, I see I mistyped in my example above, it should have been
>>>
>>> if test $slot = "A" ; setenv result $BOOT_A_LEFT ...
>>>
>>> as should hopefully be clear from the original post and the eval
>>> examples. So to reiterate, the problem is to get the contents (or
>value,
>>> if you will) of the BOOT_A_LEFT variable into the result variable,
>not
>>> setting result to the string "BOOT_A_LEFT" - but with the wrinkle
>that
>>> BOOT_A_LEFT is generated programmatically, so the code cannot
>literally
>>> mention BOOT_A_LEFT anywhere.
>>
>> Didn't I show this in my second, expanded example?
>
>I'm sorry, but no, you did not. You used the capability of the print
>(or
>rather printenv) command to take the name of a variable and print
>"name=value" to the terminal.
>
>In your example, result had the value BOOT_A_LEFT, so doing "print
>$result" meant executing the command "print BOOT_A_LEFT", and of course
>the output of that was then "BOOT_A_LEFT=boot a left".
>
>However, what I need is to get that "boot a left" value stored in some
>other variable so I can actually do further logic based on that value.
>
>> I suggest you provide a working example of shell code (say, bash, if
>> you like) to demonstrate what you really have in mind. It seems
>> I have problems understanding your verbal description.
>
>Assume BOOT_ORDER contains some permutation of "A B C", and for each
>letter x, there's a BOOT_x_LEFT counter telling how many boot attempts
>that slot has left. Now I want to find the first x in $BOOT_ORDER for
>which $BOOT_x_LEFT is positive. If all BOOT_x_LEFT are 0, say I want
>the
>sentinel value 'none'.
>
>So in bash, that might be written
>
>slot=none
>for x in $BOOT_ORDER ; do
> eval "left=\${BOOT_${x}_LEFT}"
> if [ $left -gt 0 ] ; then
>slot=$x
>break
> fi
>done
>
>Now we can work around the lack of break in the busybox shell by
>writing
>the loop so that the main body is skipped if we've found a valid slot:
>
>slot=none
>for x in $BOOT_ORDER ; do
> if [ $slot != 'none' ] ; then
>true
> else
>eval "left=\${BOOT_${x}_LEFT}"
>if [ $left -gt 0 ] ; then
> slot=$x
>fi
> fi
>done
>
>But we still can't translate this to busybox shell, because there's no
>eval. Now, I can do this with a hypothetical "env get" command which I
>just implemented to test that it works, and then the above becomes
>
>env set slot none;
>for x in $BOOT_ORDER ; do
> if test $slot != 'none' ; then
>true ;
> else
>env get left BOOT_${x}_LEFT ; # magic
>if test $left -gt 0 ; then
> env set slot $x ;
>fi;
> fi;
>done;
>
>Now, if you can implement the line marked #magic with existing
>functions, I'm all ears. Or if you can implement the semantics of this
>snippet in some other way, which does not open-code explicit references
>to BOOT_A_LEFT, BOOT_B_LEFT etc. This is what I meant when I said I'd
>prefer not to write the loop like this:
>
>env set slot none;
>for x in $BOOT_ORDER ; do
> if test $slot != 'none' ; then
>true ;
> else
>if test $x = A && test $BOOT_A_LEFT -gt 0 ; then
> env set slot A
> env set left $BOOT_A_LEFT
>elif test $x = B && test $BOOT_B_LEFT -gt 0 ; then
> env set slot B
> env set left $BOOT_B_LEFT
>elif test $x = C && test $BOOT_C_LEFT -gt 0 ; then
> env set slot C
> env set left $BOOT_C_LEFT
>fi
> fi;
>done;
>
>[yes, I also want left set as a side effect to the current value of the
>appropriate BOOT_x_LEFT].
>
>>> So just as print[env] takes the name of a variable and shows the
>>> name=value string, and one can thus say "printenv BOOT_${slot}_LEFT"
>as
>>> you did in your extended example, I could do
>>>
>>> env get result BOOT_${slot}_LEFT
>>>
>>> and get the value of the BOOT_${slot}_LEFT variable into result.
>>
>> I still fail to see why you think this cannot be done with just the
>> already existing code. Just use setenv instead of printenv in my
>> example?
>>
>>> Would you be ok with adding such an "env get" with less foot-gun
>potential?
>>
>> I'm not OK with adding any special-purpose code which can easily
>> be implemented with existing scripting capabilites.
>
>Of course not. But _I'm_ not seeing how one can actually fetch the
>value
>of one variable into another, just given the first variable's name -
>when that name is programmatically generated, e.g. as BOOT_${x}_LEFT or
>whatnot.
>
>PS: Implementation of "env get" is just:
>
RE: [PATCH v1 2/2] board: stm32: remove fdt_high and fdt_highinitrd_high
Hi, > From: Patrice CHOTARD > Sent: lundi 3 février 2020 15:11 > > For stm32 f4, f7 and h7 boards, remove fdt_high and initrd_high as they > shouldn't > be used, this allows the fdt and initrd relocation. > This implies to set CONFIG_SYS_BOOTMAPSZ to indicate the amount of > memory available to contain kernel, device tree and initrd for relocation. > > Signed-off-by: Patrice Chotard > > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH v1 1/2] board: stm32: fix extra env setings addresses
Hi, > From: Patrice CHOTARD > Sent: lundi 3 février 2020 15:11 > > For stm32f4, f7 and h7 boards, reserve: > - 4MB for kernel > - 64KB for fdt, boot script, pxefile > - the remaining memory for ramdisk > > Signed-off-by: Patrice Chotard > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH] board: stih410-b2260: remove fdt_high and initrd_high
Hi, > From: Patrice CHOTARD > Sent: lundi 3 février 2020 15:01 > > Remove fdt_high and initrd_high as they shouldn't be used, this allows the > fdt and > initrd relocation. > This implies to set CONFIG_SYS_BOOTMAPSZ to indicate the amount of > memory available to contain kernel, device tree and initrd for relocation. > > Signed-off-by: Patrice Chotard > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
Re: [PATCH v6 0/7] rsa: extend rsa_verify() for UEFI secure boot
On Mon, Jan 27, 2020 at 07:27:33PM +0900, AKASHI Takahiro wrote: > # This patch set is a prerequisite for UEFI secure boot. > > The current rsa_verify() requires five parameters for a RSA public key > for efficiency while RSA, in theory, requires only two. In addition, > those parameters are expected to come from FIT image. > > So this function won't fit very well when we want to use it for the purpose > of implementing UEFI secure boot, in particular, image authentication > as well as variable authentication, where the essential two parameters > are set to be retrieved from one of X509 certificates in signature > database. > > So, in this patch, additional three parameters will be calculated > on the fly when rsa_verify() is called without fdt which should contain > parameters above. > > This calculation heavily relies on "big-number (or multi-precision) > library." Therefore some routines from BearSSL[1] under MIT license are > imported in this implementation. See Patch#4. > # Please let me know if this is not appropriate. > > Prerequisite: > * public key parser in my "import x509/pkcs7 parser" patch[2] > > # Checkpatch will complain with lots of warnings/errors, but > # I intentionally don't fix them for maximum maintainability. > > [1] https://bearssl.org/ > [2] https://lists.denx.de/pipermail/u-boot/2019-November/390127.html At this point it needs to be rebased again. There's a ton of failures in https://gitlab.denx.de/u-boot/u-boot/pipelines/2198 which is after I did https://gitlab.denx.de/u-boot/u-boot/commit/7db0379f85995d8c7673db7b04eb36d96546c9c8 and I'll put a proper commit message on that later today and post it and CC relevant parties. It's otherwise looking good. I do want to confirm that on boards like minnowmax the slight growth in fit_image_check_sig is expected. It's only 6 bytes so it probably is and we get a larger reduction in rsa_verify all-around. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"
On 14/02/2020 12.54, Rasmus Villemoes wrote: > Now we can work around the lack of break in the busybox shell by writing ^ > But we still can't translate this to busybox shell, because there's no ^ I of course meant "U-Boot shell", sorry about that. Rasmus
[PATCH] usb: dwc3: Check that the request is valid in dwc3_gadget_giveback()
From: Jean-Jacques Hiblot
This fixes potential issues reported by klokworks:
Pointer 'req' returned from call to function 'next_request' at line 531 and
538 may be NULL and will be dereferenced in dwc3_gadget_giveback()
Signed-off-by: Jean-Jacques Hiblot
Signed-off-by: Vignesh Raghavendra
---
drivers/usb/dwc3/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4353dffb6b12..12de3b1da663 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -227,6 +227,9 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct
dwc3_request *req,
{
struct dwc3 *dwc = dep->dwc;
+ if (!req)
+ return;
+
if (req->queued) {
dep->busy_slot++;
/*
--
2.25.0
[PATCH] misc: k3_avs: Fix possible NULL pointer deference
Its possible that k3_avs_priv is NULL because the driver may not have
been probed yet. Therefore check if pointer is valid before
dereferencing it.
Signed-off-by: Vignesh Raghavendra
---
drivers/misc/k3_avs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
index c19c3c0646b7..adaf75b7165d 100644
--- a/drivers/misc/k3_avs.c
+++ b/drivers/misc/k3_avs.c
@@ -190,6 +190,10 @@ int k3_avs_notify_freq(int dev_id, int clk_id, u32 freq)
struct k3_avs_privdata *priv = k3_avs_priv;
struct vd_data *vd;
+ /* Driver may not be probed yet */
+ if (!priv)
+ return -EINVAL;
+
for (vd = priv->vd_config->vds; vd->id >= 0; vd++) {
if (vd->dev_id != dev_id || vd->clk_id != clk_id)
continue;
--
2.25.0
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
On Fri, Feb 14, 2020 at 6:36 AM Michal Simek wrote: > I think it will be the best to take any of your example and simply > create a series where this is applied to see if that code looks better > then before. Applying this without usage doesn't make sense. Agreed. SYS_SUPPLIER is introduced in this patch, but there is currently no user.
Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
On Fri, 14 Feb 2020 at 13:04, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > -Original Message- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: Friday, February 14, 2020 7:33 PM > > To: Chang, Abner (HPS SW/FW Technologist) > > Cc: Alexander Graf ; Atish Patra ; > > Heinrich Schuchardt ; U-Boot Mailing List > b...@lists.denx.de>; Atish Patra ; > > l...@nuviainc.com > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > > > On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist) > > wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Alexander Graf [mailto:ag...@csgraf.de] > > > > Sent: Friday, February 14, 2020 4:07 PM > > > > To: Chang, Abner (HPS SW/FW Technologist) > > > > Cc: Atish Patra ; Ard Biesheuvel > > > > ; Heinrich Schuchardt > > > > ; U-Boot Mailing List ; > > > > Atish Patra ; l...@nuviainc.com > > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI > > > > setup > > > > > > > > > > > > > > > > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW > > > > > Technologist) > > > > : > > > > > > > > > ... > > > > The table from this link https://github.com/riscv/riscv- > > > > smbios/blob/master/RISCV-SMBIOS.md > > > > > Offset 3 is HART ID, and offset 13h is the boolean indicates this > > > > > hart is the > > > > boot hart. > > > > > > > > > >> kernel. How difficult is to modify the DT in EDK2 ? > > > > >> > > > > > I never used DT before on PC/Server project. However, the DT code > > > > > is over > > > > there in edk2 repo which mostly used by ARM platforms. I don’t think > > > > it is difficult to adopt it though. > > > > > > > > Yes, some arm platforms already transform the DT just fine. Let's > > > > really please not use SMBIOS for anything boot or system > > > > configuration related: its purpose is in general purely informational. > > > As DT to embedded system, SMBIOS provides system > > information/configuration on most PC/Server platforms. Especially to pre-OS > > applications such as EFI diagnostic tool, factory/customer deployment tools, > > pre-OS system configuration, network boot image and EFI OS boot loader as > > well. The intention of RISC-V SMBIOS is support above applications using > > single image for the RISC-V core variants, Non ACPI-aware OS is also part of > > this scope, but it is rare though. > > > If you are booting to OS which is actually well understand DT then just > > > use > > DT, but for PC/Server industry, SMBIOS would be still our choice before OS. > > > We may have to define the corresponding syntax If DT doesn't have it for > > boot HART information. RISC-V System Description Task Group (f it formed) > > would be a good place to bring this topic. > > > Maybe you can support both DT or SMBIOS to retrieve the information you > > need on demand... > > > > > > > SMBIOS is an informational protocol. Firmware or OS loaders should not rely > > on it for low-level things like the hart id. > Hart ID is just one of the information in type 44 which is the same as the > processor information provided in type 4. > Fine. But that doesn't mean we should be parsing SMBIOS tables in the Linux startup code. > > > > > > > > > > So yes, unless I hear really good arguments against passing it via > > > > /chosen in DT, I'd strongly prefer that mechanism. For ACPI (if it > > > > ever happens), there would be a special ACPI table for it anyway. > > > Yes, we do have an ECR for ACPI spec to report the RISC-V core > > characteristic which is similar to what we done for SMBIOS. > > > > > > > So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and we'll > > always have to parse two sets of tables, just to discover the hart id. I > > don't > > think that makes sense at all, to be honest. > As I said, SMBIOS is mostly for pre OS applications, Type 42 is a good > example, the Host interface used to talk to BMC and Redfish service in pre-OS > environment (also runtime OS). > For OS boot, maybe OS (like Windows) still retrieves information from it > before ACPI enable. > > I have no preference of using which way to get boot hard ID for the boot > process, either to get it from DT, SMBIOS or ACPI seems to me the same... > just the information is provided over there > > > > > SMBIOS is wonderful for the sysadmin to look at the model numbers of the > > installed DIMMs etc. But for core boot stuff, we really should avoid it. > Security consideration? What security considerations did you have in mind?
[PATCH 3/3] ARM: uniphier: detect the base of micro support card at run-time
The base address 0x43f0 is no longer true for the future SoC.
Extract the base address from the device tree.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/micro-support-card.c | 43 +++--
1 file changed, 31 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-uniphier/micro-support-card.c
b/arch/arm/mach-uniphier/micro-support-card.c
index 46879019fdaa..c71470a20429 100644
--- a/arch/arm/mach-uniphier/micro-support-card.c
+++ b/arch/arm/mach-uniphier/micro-support-card.c
@@ -1,39 +1,58 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2012-2015 Panasonic Corporation
- * Copyright (C) 2015-2016 Socionext Inc.
+ * Copyright (C) 2015-2020 Socionext Inc.
* Author: Masahiro Yamada
*/
#include
+#include
+#include
#include
#include
#include "micro-support-card.h"
-#define MICRO_SUPPORT_CARD_BASE0x43f0
-#define SMC911X_BASE ((MICRO_SUPPORT_CARD_BASE) + 0x0)
-#define LED_BASE ((MICRO_SUPPORT_CARD_BASE) + 0x9)
-#define NS16550A_BASE ((MICRO_SUPPORT_CARD_BASE) + 0xb)
-#define MICRO_SUPPORT_CARD_RESET ((MICRO_SUPPORT_CARD_BASE) + 0xd0034)
-#define MICRO_SUPPORT_CARD_REVISION((MICRO_SUPPORT_CARD_BASE) + 0xd00E0)
+#define SMC911X_OFFSET 0x0
+#define LED_OFFSET 0x9
+#define NS16550A_OFFSET0xb
+#define MICRO_SUPPORT_CARD_RESET 0xd0034
+#define MICRO_SUPPORT_CARD_REVISION0xd00e0
static bool support_card_found;
+static void __iomem *support_card_base;
static void support_card_detect(void)
{
DECLARE_GLOBAL_DATA_PTR;
const void *fdt = gd->fdt_blob;
int offset;
+ u64 addr, addr2;
offset = fdt_node_offset_by_compatible(fdt, 0, "smsc,lan9118");
if (offset < 0)
return;
+ addr = fdt_get_base_address(fdt, offset);
+ if (addr == OF_BAD_ADDR)
+ return;
+ addr -= SMC911X_OFFSET;
+
offset = fdt_node_offset_by_compatible(fdt, 0, "ns16550a");
if (offset < 0)
return;
+ addr2 = fdt_get_base_address(fdt, offset);
+ if (addr2 == OF_BAD_ADDR)
+ return;
+ addr2 -= NS16550A_OFFSET;
+
+ /* sanity check */
+ if (addr != addr2)
+ return;
+
+ support_card_base = ioremap(addr, 0x10);
+
support_card_found = true;
}
@@ -45,19 +64,19 @@ static void support_card_detect(void)
*/
static void support_card_reset_deassert(void)
{
- writel(0x0001, MICRO_SUPPORT_CARD_RESET);
+ writel(0x0001, support_card_base + MICRO_SUPPORT_CARD_RESET);
}
static void support_card_reset(void)
{
- writel(0x00020003, MICRO_SUPPORT_CARD_RESET);
+ writel(0x00020003, support_card_base + MICRO_SUPPORT_CARD_RESET);
}
static int support_card_show_revision(void)
{
u32 revision;
- revision = readl(MICRO_SUPPORT_CARD_REVISION);
+ revision = readl(support_card_base + MICRO_SUPPORT_CARD_REVISION);
revision &= 0xff;
/* revision 3.6.x card changed the revision format */
@@ -94,7 +113,7 @@ int board_eth_init(bd_t *bis)
if (!support_card_found)
return 0;
- return smc911x_initialize(0, SMC911X_BASE);
+ return smc911x_initialize(0, (unsigned long)support_card_base +
SMC911X_OFFSET);
}
#endif
@@ -264,5 +283,5 @@ void led_puts(const char *s)
s++;
}
- writel(~val, LED_BASE);
+ writel(~val, support_card_base + LED_OFFSET);
}
--
2.17.1
[PATCH 2/3] ARM: uniphier: remove workaround for the NAND write protect
This workaround was previously needed for LD4, Pro4, sLD8, Pro5
SoCs. The boot ROM does not touch this register for PXs2/LD6b or
later.
Now that the reset signal of the Denali NAND controller is always
asserted in board_init() then deasserted in the driver, the
WRITE_PROTECT register gets back to the default value, which means
the write protect is deasserted.
This workaround can go away entirely.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/board_late_init.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/arch/arm/mach-uniphier/board_late_init.c
b/arch/arm/mach-uniphier/board_late_init.c
index 793283058c35..378aad0c9c45 100644
--- a/arch/arm/mach-uniphier/board_late_init.c
+++ b/arch/arm/mach-uniphier/board_late_init.c
@@ -14,25 +14,9 @@
#include
#include
#include
-#include <../drivers/mtd/nand/raw/denali.h>
#include "init.h"
-static void nand_denali_wp_disable(void)
-{
-#ifdef CONFIG_NAND_DENALI
- /*
-* Since the boot rom enables the write protection for NAND boot mode,
-* it must be disabled somewhere for "nand write", "nand erase", etc.
-* The workaround is here to not disturb the Denali NAND controller
-* driver just for a really SoC-specific thing.
-*/
- void __iomem *denali_reg = (void __iomem *)CONFIG_SYS_NAND_REGS_BASE;
-
- writel(WRITE_PROTECT__FLAG, denali_reg + WRITE_PROTECT);
-#endif
-}
-
static void uniphier_set_env_fdt_file(void)
{
DECLARE_GLOBAL_DATA_PTR;
@@ -114,7 +98,6 @@ int board_late_init(void)
case BOOT_DEVICE_NAND:
printf("NAND Boot");
env_set("bootdev", "nand");
- nand_denali_wp_disable();
break;
case BOOT_DEVICE_NOR:
printf("NOR Boot");
--
2.17.1
[PATCH 1/3] ARM: uniphier: move NAND reset assertion to U-Boot proper from SPL
The comment /* deassert reset */ is wrong. It asserts the reset.
It no longer needs to stay in SPL. The NAND controller reset is
handled in the driver. So, this assert can be moved to the
board_init() of U-Boot proper.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/Makefile| 1 +
arch/arm/mach-uniphier/board_init.c| 4 ++
arch/arm/mach-uniphier/clk/clk-early-ld4.c | 7
arch/arm/mach-uniphier/init.h | 8
arch/arm/mach-uniphier/nand-reset.c| 43 ++
5 files changed, 56 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/mach-uniphier/nand-reset.c
diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
index 115af244cd55..769778cf5083 100644
--- a/arch/arm/mach-uniphier/Makefile
+++ b/arch/arm/mach-uniphier/Makefile
@@ -22,6 +22,7 @@ endif
obj-$(CONFIG_MICRO_SUPPORT_CARD) += micro-support-card.o
obj-y += pinctrl-glue.o
obj-$(CONFIG_MMC) += mmc-first-dev.o
+obj-$(CONFIG_NAND_DENALI) += nand-reset.o
obj-y += fdt-fixup.o
endif
diff --git a/arch/arm/mach-uniphier/board_init.c
b/arch/arm/mach-uniphier/board_init.c
index 99727a300420..4f9cd6e722c1 100644
--- a/arch/arm/mach-uniphier/board_init.c
+++ b/arch/arm/mach-uniphier/board_init.c
@@ -141,6 +141,10 @@ int board_init(void)
support_card_late_init();
+ led_puts("U4");
+
+ uniphier_nand_reset_assert();
+
led_puts("Uboo");
return 0;
diff --git a/arch/arm/mach-uniphier/clk/clk-early-ld4.c
b/arch/arm/mach-uniphier/clk/clk-early-ld4.c
index f32f78dd26d8..0f9ce6509768 100644
--- a/arch/arm/mach-uniphier/clk/clk-early-ld4.c
+++ b/arch/arm/mach-uniphier/clk/clk-early-ld4.c
@@ -15,13 +15,6 @@ void uniphier_ld4_early_clk_init(void)
{
u32 tmp;
- /* deassert reset */
- if (spl_boot_device() != BOOT_DEVICE_NAND) {
- tmp = readl(sc_base + SC_RSTCTRL);
- tmp &= ~SC_RSTCTRL_NRST_NAND;
- writel(tmp, sc_base + SC_RSTCTRL);
- };
-
/* provide clocks */
tmp = readl(sc_base + SC_CLKCTRL);
tmp |= SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI;
diff --git a/arch/arm/mach-uniphier/init.h b/arch/arm/mach-uniphier/init.h
index 9dc5b885a5fe..3c77f4885348 100644
--- a/arch/arm/mach-uniphier/init.h
+++ b/arch/arm/mach-uniphier/init.h
@@ -101,6 +101,14 @@ unsigned int uniphier_boot_device_raw(void);
int uniphier_have_internal_stm(void);
int uniphier_boot_from_backend(void);
int uniphier_pin_init(const char *pinconfig_name);
+
+#ifdef CONFIG_NAND_DENALI
+void uniphier_nand_reset_assert(void);
+#else
+static inline void uniphier_nand_reset_assert(void)
+{
+}
+#endif
#ifdef CONFIG_ARM64
void uniphier_mem_map_init(unsigned long dram_base, unsigned long dram_size);
#else
diff --git a/arch/arm/mach-uniphier/nand-reset.c
b/arch/arm/mach-uniphier/nand-reset.c
new file mode 100644
index ..b8f75a5f189f
--- /dev/null
+++ b/arch/arm/mach-uniphier/nand-reset.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0 or later
+/*
+ * Copyright (C) 2020 Socionext Inc.
+ * Author: Masahiro Yamada
+ */
+
+#include
+#include
+#include
+#include
+
+#include "init.h"
+
+/*
+ * Assert the Denali NAND controller reset if found.
+ *
+ * On LD4, the bootstrap process starts running after power-on reset regardless
+ * of the boot mode, here the pin-mux is not necessarily set up for NAND, then
+ * the controller is stuck. Assert the controller reset here, and should be
+ * deasserted in the driver after the pin-mux is correctly handled. For other
+ * SoCs, the bootstrap runs only when the boot mode selects ONFi, but it is yet
+ * effective when the boot swap is on. So, the reset should be asserted anyway.
+ */
+void uniphier_nand_reset_assert(void)
+{
+ struct udevice *dev;
+ struct reset_ctl_bulk resets;
+ int ret;
+
+ ret = uclass_find_first_device(UCLASS_MTD, );
+ if (ret)
+ return;
+
+ /* make sure this is the Denali NAND controller */
+ if (strcmp(dev->driver->name, "denali-nand-dt"))
+ return;
+
+ ret = reset_get_bulk(dev, );
+ if (ret)
+ return;
+
+ reset_assert_bulk();
+}
--
2.17.1
Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"
On 13/02/2020 16.55, Wolfgang Denk wrote:
> Dear Rasmus,
>
> In message you wrote:
>>
>> I'm sorry, I see I mistyped in my example above, it should have been
>>
>> if test $slot = "A" ; setenv result $BOOT_A_LEFT ...
>>
>> as should hopefully be clear from the original post and the eval
>> examples. So to reiterate, the problem is to get the contents (or value,
>> if you will) of the BOOT_A_LEFT variable into the result variable, not
>> setting result to the string "BOOT_A_LEFT" - but with the wrinkle that
>> BOOT_A_LEFT is generated programmatically, so the code cannot literally
>> mention BOOT_A_LEFT anywhere.
>
> Didn't I show this in my second, expanded example?
I'm sorry, but no, you did not. You used the capability of the print (or
rather printenv) command to take the name of a variable and print
"name=value" to the terminal.
In your example, result had the value BOOT_A_LEFT, so doing "print
$result" meant executing the command "print BOOT_A_LEFT", and of course
the output of that was then "BOOT_A_LEFT=boot a left".
However, what I need is to get that "boot a left" value stored in some
other variable so I can actually do further logic based on that value.
> I suggest you provide a working example of shell code (say, bash, if
> you like) to demonstrate what you really have in mind. It seems
> I have problems understanding your verbal description.
Assume BOOT_ORDER contains some permutation of "A B C", and for each
letter x, there's a BOOT_x_LEFT counter telling how many boot attempts
that slot has left. Now I want to find the first x in $BOOT_ORDER for
which $BOOT_x_LEFT is positive. If all BOOT_x_LEFT are 0, say I want the
sentinel value 'none'.
So in bash, that might be written
slot=none
for x in $BOOT_ORDER ; do
eval "left=\${BOOT_${x}_LEFT}"
if [ $left -gt 0 ] ; then
slot=$x
break
fi
done
Now we can work around the lack of break in the busybox shell by writing
the loop so that the main body is skipped if we've found a valid slot:
slot=none
for x in $BOOT_ORDER ; do
if [ $slot != 'none' ] ; then
true
else
eval "left=\${BOOT_${x}_LEFT}"
if [ $left -gt 0 ] ; then
slot=$x
fi
fi
done
But we still can't translate this to busybox shell, because there's no
eval. Now, I can do this with a hypothetical "env get" command which I
just implemented to test that it works, and then the above becomes
env set slot none;
for x in $BOOT_ORDER ; do
if test $slot != 'none' ; then
true ;
else
env get left BOOT_${x}_LEFT ; # magic
if test $left -gt 0 ; then
env set slot $x ;
fi;
fi;
done;
Now, if you can implement the line marked #magic with existing
functions, I'm all ears. Or if you can implement the semantics of this
snippet in some other way, which does not open-code explicit references
to BOOT_A_LEFT, BOOT_B_LEFT etc. This is what I meant when I said I'd
prefer not to write the loop like this:
env set slot none;
for x in $BOOT_ORDER ; do
if test $slot != 'none' ; then
true ;
else
if test $x = A && test $BOOT_A_LEFT -gt 0 ; then
env set slot A
env set left $BOOT_A_LEFT
elif test $x = B && test $BOOT_B_LEFT -gt 0 ; then
env set slot B
env set left $BOOT_B_LEFT
elif test $x = C && test $BOOT_C_LEFT -gt 0 ; then
env set slot C
env set left $BOOT_C_LEFT
fi
fi;
done;
[yes, I also want left set as a side effect to the current value of the
appropriate BOOT_x_LEFT].
>> So just as print[env] takes the name of a variable and shows the
>> name=value string, and one can thus say "printenv BOOT_${slot}_LEFT" as
>> you did in your extended example, I could do
>>
>> env get result BOOT_${slot}_LEFT
>>
>> and get the value of the BOOT_${slot}_LEFT variable into result.
>
> I still fail to see why you think this cannot be done with just the
> already existing code. Just use setenv instead of printenv in my
> example?
>
>> Would you be ok with adding such an "env get" with less foot-gun potential?
>
> I'm not OK with adding any special-purpose code which can easily
> be implemented with existing scripting capabilites.
Of course not. But _I'm_ not seeing how one can actually fetch the value
of one variable into another, just given the first variable's name -
when that name is programmatically generated, e.g. as BOOT_${x}_LEFT or
whatnot.
PS: Implementation of "env get" is just:
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -386,6 +386,20 @@ static int do_env_set(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
return _do_env_set(flag, argc, argv, H_INTERACTIVE);
}
+static int do_env_get(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
+{
+ char *local_args[4];
+
+ if (argc != 3)
+ return CMD_RET_USAGE;
+ local_args[0] = argv[0];
+ local_args[1] = argv[1];
+ local_args[2] = env_get(argv[2]);
+ local_args[3] = NULL;
+
+ return _do_env_set(flag, argc, local_args, H_INTERACTIVE);
+}
+
/*
* Prompt
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
On 14. 02. 20 12:37, Jens Rehsack wrote:
>
>
>> Am 14.02.2020 um 10:36 schrieb Michal Simek :
>>
>> On 13. 02. 20 18:48, Tom Rini wrote:
>>> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
> Am 13.02.2020 um 16:01 schrieb Tom Rini :
>
> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
>
>> From: Jens Rehsack
>>
>> Introduce SUPPLIER analogous to VENDOR to allow (from customer
>> perspective)
>> a VENDOR using it's SUPPLIER's common/ code.
>>
>> This is reasonable, when a VENDOR (from customer perspective) builds
>> several machines sharing some features (e.g. some FPGA which has to be
>> initialized during u-boot) but wants to use common NXP or Samsung code
>> for the BSP instead of copying and create merge overhead.
>>
>> Signed-off-by: Jens Rehsack
>> ---
>> Makefile | 4 +++-
>> arch/Kconfig | 12
>> config.mk| 6 +-
>> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> Can you provide a follow-up where this it clearer / easier to do
> something than today? Thanks!
Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
NXP code for the Management Complex is needed. I2C code either - this
covers board/freescale/common/...
Given you build machines from there with different SoCs under a
new label - let's call it SuperLink, so you have
* board/freescale/common
* board/superlink/common
* board/superlink/legacy-tune <-- based on some PowerPC
* board/superlink/easy-tune <-- based on LS2088
* board/superlink/heavy-tune <-- based on LX2160
All *-tune machines the customer buys from SuperLink have a
similar FPGA (there is a little bit more, but for the vision
it's probably better to stay small) and a similar external
PMIC/BMC.
But SuperLink still uses code from board/freescale/common (their
supplier) and it's not reasonable to copy those.
I rate all this not suitable for a commit message. How do
you suggest to proceed?
>>>
>>> Well, lets add in Michal as there are Zynq examples that could be
>>> cleaned up with what you're proposing. Similarly, Vanessa and Otavio
>>> might have thoughts here as they could rework some of the TechNexion
>>> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved
>>> from board/ to some sub-directory?). Thanks all!
>>
>> I think it will be the best to take any of your example and simply
>> create a series where this is applied to see if that code looks better
>> then before. Applying this without usage doesn't make sense.
>
> I don't understand what you propose. Do you ask me to show internal
> sources or the result of `find {...} -type f` or the content of our
> Kconfig or defconfig?
>
> I'll try to do as much as I can (I'm sure, showing internal code won't
> be permitted).
>
>> For zynq there are some boards like topic, bitmain, opalkelly which are
>> staying in own folder but sourcing zynq board.c.
>
> As said, freescale common code stays in board/freescale/common/ - and
> our code is in board/"superlink"/...
I expect that you will find any example in the current code which can
use this feature. It means you can enable this feature and any current
configuration will really use it and will be regularly used/covered by
testing.
Adding feature which none will use in mainline should be IMHO nacked.
Thanks,
Michal
Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > -Original Message- > > From: Alexander Graf [mailto:ag...@csgraf.de] > > Sent: Friday, February 14, 2020 4:07 PM > > To: Chang, Abner (HPS SW/FW Technologist) > > Cc: Atish Patra ; Ard Biesheuvel > > ; Heinrich Schuchardt ; > > U-Boot Mailing List ; Atish Patra > > ; l...@nuviainc.com > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > > > > > > > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW Technologist) > > : > > > ... > > The table from this link https://github.com/riscv/riscv- > > smbios/blob/master/RISCV-SMBIOS.md > > > Offset 3 is HART ID, and offset 13h is the boolean indicates this hart is > > > the > > boot hart. > > > > > >> kernel. How difficult is to modify the DT in EDK2 ? > > >> > > > I never used DT before on PC/Server project. However, the DT code is over > > there in edk2 repo which mostly used by ARM platforms. I don’t think it is > > difficult to adopt it though. > > > > Yes, some arm platforms already transform the DT just fine. Let's really > > please not use SMBIOS for anything boot or system configuration related: its > > purpose is in general purely informational. > As DT to embedded system, SMBIOS provides system information/configuration on > most PC/Server platforms. Especially to pre-OS applications such as EFI > diagnostic tool, factory/customer deployment tools, pre-OS system > configuration, network boot image and EFI OS boot loader as well. The > intention of RISC-V SMBIOS is support above applications using single image > for the RISC-V core variants, Non ACPI-aware OS is also part of this scope, > but it is rare though. > If you are booting to OS which is actually well understand DT then just use > DT, but for PC/Server industry, SMBIOS would be still our choice before OS. > We may have to define the corresponding syntax If DT doesn't have it for boot > HART information. RISC-V System Description Task Group (f it formed) would be > a good place to bring this topic. > Maybe you can support both DT or SMBIOS to retrieve the information you need > on demand... > SMBIOS is an informational protocol. Firmware or OS loaders should not rely on it for low-level things like the hart id. > > > > So yes, unless I hear really good arguments against passing it via /chosen > > in > > DT, I'd strongly prefer that mechanism. For ACPI (if it ever happens), there > > would be a special ACPI table for it anyway. > Yes, we do have an ECR for ACPI spec to report the RISC-V core characteristic > which is similar to what we done for SMBIOS. > So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and we'll always have to parse two sets of tables, just to discover the hart id. I don't think that makes sense at all, to be honest. SMBIOS is wonderful for the sysadmin to look at the model numbers of the installed DIMMs etc. But for core boot stuff, we really should avoid it.
[PATCH] sandbox: also restore terminal settings when killed by SIGINT
Hitting Ctrl-C is a documented way to exit the sandbox, but it is not
actually equivalent to the reset command. The latter, since it follows
normal process exit, takes care to reset terminal settings and
restoring the O_NONBLOCK behaviour of stdin (and, in a terminal, that
is usually the same file description as stdout and stderr, i.e. some
/dev/pts/NN).
Failure to restore (remove) O_NONBLOCK from stdout/stderr can cause
very surprising and hard to debug problems back in the terminal. For
example, I had "make -j8" consistently failing without much
information about just exactly what went wrong, but sometimes I did
get a "echo: write error". I was at first afraid my disk was getting
bad, but then a simple "dmesg" _also_ failed with write error - so it
was writing to the terminal that was buggered. And both "make -j8" and
dmesg in another terminal window worked just fine.
So install a SIGINT handler so that if the chosen terminal
mode (cooked or raw-with-sigs) means Ctrl-C sends a SIGINT, we will
still call os_fd_restore(), then reraise the signal and die as usual
from SIGINT.
Before:
$ grep flags /proc/$$/fdinfo/1
flags: 0102002
$ ./u-boot
# hit Ctrl-C
$ grep flags /proc/$$/fdinfo/1
flags: 0106002
After:
$ grep flags /proc/$$/fdinfo/1
flags: 0102002
$ ./u-boot
# hit Ctrl-C
$ grep flags /proc/$$/fdinfo/1
flags: 0102002
Signed-off-by: Rasmus Villemoes
---
arch/sandbox/cpu/os.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index f7c73e3a0b..e7ec892bdf 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -175,6 +176,13 @@ void os_fd_restore(void)
}
}
+static void os_sigint_handler(int sig)
+{
+ os_fd_restore();
+ signal(SIGINT, SIG_DFL);
+ raise(SIGINT);
+}
+
/* Put tty into raw mode so and work */
void os_tty_raw(int fd, bool allow_sigs)
{
@@ -205,6 +213,7 @@ void os_tty_raw(int fd, bool allow_sigs)
term_setup = true;
atexit(os_fd_restore);
+ signal(SIGINT, os_sigint_handler);
}
void *os_malloc(size_t length)
--
2.23.0
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On 14/02/20, Anatolij Gustschin wrote:
> On Fri, 14 Feb 2020 09:50:54 +0530
> Lokesh Vutla lokeshvu...@ti.com wrote:
>
> > On 13/02/20 10:42 PM, Neil Armstrong wrote:
> > > Hi,
> > >
> > > On 03/02/2020 14:59, Oliver Graute wrote:
> > >> The conga-imx8 board isn't booting without this revert. Can someone tell
> > >> me
> > >> what I need to Do so that this revert is not necessary?
> >
> > Can you give more details on where the failure is happening?(logs would
> > really
> > help).
>
> On i.MX8QXP based SoM running U-Boot v2020.04-rc2 with below patch the
> v4.14.98 kernel from NXP BSP boots:
>
> diff --git a/arch/arm/mach-imx/imx8/fdt.c b/arch/arm/mach-imx/imx8/fdt.c
> index 65c8ac1a7e..cf79a12f42 100644
> --- a/arch/arm/mach-imx/imx8/fdt.c
> +++ b/arch/arm/mach-imx/imx8/fdt.c
> @@ -280,7 +280,9 @@ int ft_system_setup(void *blob, bd_t *bd)
> {
> int ret;
>
> + /*
> update_fdt_with_owned_resources(blob);
> + */
>
> if (is_imx8qm()) {
> ret = config_smmu_fdt(blob);
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index 444e34b492..a218f481b5 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -194,9 +194,18 @@ int device_remove(struct udevice *dev, uint flags)
> }
> }
>
> - if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
> - (dev != gd->cur_serial_dev))
> + if (!(dev->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
> + (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> + (dev != gd->cur_serial_dev)) {
> + dm_warn("%s: OFF '%s', uclass pd %d\n",
> + __func__, dev->name,
> + device_get_uclass_id(dev) == UCLASS_POWER_DOMAIN);
> dev_power_domain_off(dev);
> + } else {
> + dm_warn("%s: '%s', uclass pd %d\n",
> + __func__, dev->name,
> + device_get_uclass_id(dev) == UCLASS_POWER_DOMAIN);
> + }
>
> if (flags_remove(flags, drv->flags)) {
> device_free(dev);
>
> The generated debug log:
thx I did the same as Anatolij on my imx8qm congatec board:
done
Bytes transferred = 21224 (52e8 hex)
## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
Using Device Tree in place at 8300, end 830082e7
Starting kernel ...
device_remove: OFF 'clk', uclass pd 0
device_remove: OFF 'hoggrp', uclass pd 0
device_remove: OFF 'fec1grp', uclass pd 0
device_remove: OFF 'lpuart0grp', uclass pd 0
device_remove: OFF 'usdhc1grp', uclass pd 0
device_remove: OFF 'usdhc2grpgpio', uclass pd 0
device_remove: OFF 'usdhc2grp', uclass pd 0
device_remove: OFF 'usdhc3grpgpio', uclass pd 0
device_remove: OFF 'usdhc3grp', uclass pd 0
device_remove: OFF 'imx8qm-qmx8', uclass pd 0
device_remove: OFF 'iomuxc', uclass pd 0
device_remove: OFF 'mu@5d1c', uclass pd 0
device_remove: 'lsio_gpio0', uclass pd 1
device_remove: 'lsio_gpio1', uclass pd 1
device_remove: 'lsio_gpio2', uclass pd 1
device_remove: 'lsio_gpio4', uclass pd 1
device_remove: 'lsio_gpio5', uclass pd 1
device_remove: 'lsio_power_domain', uclass pd 1
device_remove: 'conn_sdhc0', uclass pd 1
device_remove: 'conn_sdhc1', uclass pd 1
device_remove: 'conn_sdhc2', uclass pd 1
device_remove: 'conn_enet0', uclass pd 1
device_remove: 'connectivity_power_domain', uclass pd 1
device_remove: 'dma_lpuart0', uclass pd 1
device_remove: 'dma_power_domain', uclass pd 1
device_remove: OFF 'imx8qm-pm', uclass pd 0
device_remove: OFF 'gpio@5d08', uclass pd 0
power_domain_get_by_index() power_domain_get_by_index(dev=fdaea0f0,
power_domain=fdae0118)
imx8_power_domain_of_xlate()
imx8_power_domain_of_xlate(power_domain=fdae0118)
imx8_power_domain_request()
imx8_power_domain_request(power_domain=fdae0118)
power_domain_off() power_domain_off(power_domain=fdae0118)
imx8_power_domain_off() imx8_power_domain_off(power_domain=fdae0118)
imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_gpio0, state_on 1
imx8_power_domain_off_node() lsio_gpio0 is powered off
imx8_power_domain_off_parentnodes() imx8_power_domain_off_parentnodes,
lsio_power_domain, state_on 1
imx8_power_domain_off_parentnodes() sibling lsio_gpio1, state_on 1
device_remove: 'lsio_gpio0', uclass pd 1
device_remove: OFF 'gpio@5d09', uclass pd 0
power_domain_get_by_index() power_domain_get_by_index(dev=fdaea1d0,
power_domain=fdae0118)
imx8_power_domain_of_xlate()
imx8_power_domain_of_xlate(power_domain=fdae0118)
imx8_power_domain_request()
imx8_power_domain_request(power_domain=fdae0118)
power_domain_off() power_domain_off(power_domain=fdae0118)
imx8_power_domain_off() imx8_power_domain_off(power_domain=fdae0118)
imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_gpio1, state_on 1
imx8_power_domain_off_node() lsio_gpio1 is powered off
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On 14/02/20, Lokesh Vutla wrote: > > > On 14/02/20 2:48 PM, Oliver Graute wrote: > > On 14/02/20, Lokesh Vutla wrote: > >> > >> > >> On 13/02/20 10:42 PM, Neil Armstrong wrote: > >>> Hi, > >>> > >>> On 03/02/2020 14:59, Oliver Graute wrote: > The conga-imx8 board isn't booting without this revert. Can someone tell > me > what I need to Do so that this revert is not necessary? > >> > >> Can you give more details on where the failure is happening?(logs would > >> really > >> help). > > > > without that revert patch u-boot is stuck at "Starting kernel ..." > > Is there a way to get more details here? currently I don't know howto > > debug that power-domain stuff deeper. > > Can you enable debug prints in: > - drivers/power/domain/power-domain-uclass.c > - drivers/power/domain/imx8-power-domain*.c > > and provide the logs? this will help which power-domain is causing the issue. thx a lot that helped. So it looks like the board is in some endless loop with lsio_power_domain. here the log: Loading: # 2 MiB/s done Bytes transferred = 21224 (52e8 hex) ## Flattened Device Tree blob at 8300 Booting using the fdt blob at 0x8300 Using Device Tree in place at 8300, end 830082e7 Starting kernel ... power_domain_get_by_index() power_domain_get_by_index(dev=fdae88f0, power_domain=fdae0058) imx8_power_domain_of_xlate() imx8_power_domain_of_xlate(power_domain=fdae0058) imx8_power_domain_request() imx8_power_domain_request(power_domain=fdae0058) power_domain_off() power_domain_off(power_domain=fdae0058) imx8_power_domain_off() imx8_power_domain_off(power_domain=fdae0058) imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_power_domain, state_on 1 imx8_power_domain_off() Can't power off the node of dev lsio_power_domain, ret = -1 power_domain_get_by_index() power_domain_get_by_index(dev=fdae88f0, power_domain=fdadff48) imx8_power_domain_of_xlate() imx8_power_domain_of_xlate(power_domain=fdadff48) imx8_power_domain_request() imx8_power_domain_request(power_domain=fdadff48) power_domain_off() power_domain_off(power_domain=fdadff48) imx8_power_domain_off() imx8_power_domain_off(power_domain=fdadff48) imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_power_domain, state_on 1 imx8_power_domain_off() Can't power off the node of dev lsio_power_domain, ret = -1 power_domain_get_by_index() power_domain_get_by_index(dev=fdae88f0, power_domain=fdadfe38) imx8_power_domain_of_xlate() imx8_power_domain_of_xlate(power_domain=fdadfe38) imx8_power_domain_request() imx8_power_domain_request(power_domain=fdadfe38) power_domain_off() power_domain_off(power_domain=fdadfe38) imx8_power_domain_off() imx8_power_domain_off(power_domain=fdadfe38) imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_power_domain, state_on 1 imx8_power_domain_off() Can't power off the node of dev lsio_power_domain, ret = -1 power_domain_get_by_index() power_domain_get_by_index(dev=fdae88f0, power_domain=fdadfd28) imx8_power_domain_of_xlate() imx8_power_domain_of_xlate(power_domain=fdadfd28) imx8_power_domain_request() imx8_power_domain_request(power_domain=fdadfd28) power_domain_off() power_domain_off(power_domain=fdadfd28) imx8_power_domain_off() imx8_power_domain_off(power_domain=fdadfd28) imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_power_domain, state_on 1 imx8_power_domain_off() Can't power off the node of dev lsio_power_domain, ret = -1 power_domain_get_by_index() power_domain_get_by_index(dev=fdae88f0, power_domain=fdadfc18) imx8_power_domain_of_xlate() imx8_power_domain_of_xlate(power_domain=fdadfc18) imx8_power_domain_request() imx8_power_domain_request(power_domain=fdadfc18) power_domain_off() power_domain_off(power_domain=fdadfc18) imx8_power_domain_off() imx8_power_domain_off(power_domain=fdadfc18) imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_power_domain, state_on 1 imx8_power_domain_off() Can't power off the node of dev lsio_power_domain, ret = -1 power_domain_get_by_index() power_domain_get_by_index(dev=fdae88f0, power_domain=fdadfb08) imx8_power_domain_of_xlate() imx8_power_domain_of_xlate(power_domain=fdadfb08) imx8_power_domain_request() imx8_power_domain_request(power_domain=fdadfb08) power_domain_off() power_domain_off(power_domain=fdadfb08) imx8_power_domain_off() imx8_power_domain_off(power_domain=fdadfb08) imx8_power_domain_off_node() imx8_power_domain_off_node, lsio_power_domain, state_on 1 imx8_power_domain_off() Can't power off the node of dev lsio_power_domain, ret = -1 power_domain_get_by_index() power_domain_get_by_index(dev=fdae88f0, power_domain=fdadf9f8)
RE: [PATCH] tools: mkimage: fix STM32 image format for big endian hosts
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 15:42 > > From: Antonio Borneo > > Two header fields are not properly converted to little endian before > assignment, > resulting in incorrect header while executing mkimage on big endian hosts. > > Convert the value of the header fields image_checksum and edcsa_algorithm to > little endian before the assignment. > > Signed-off-by: Antonio Borneo > Reviewed-by: Patrick DELAUNAY > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 3/4] pinctrl: stmfx: update the result type of dm_i2c_reg_read
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:44 > > Use int as result of dm_i2c_reg_read to avoid warning with > W=1 (warning: comparison is always false due to limited range of data type [- > Wtype-limits]) > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 2/4] board: stm32mp1: change dfu function to static
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:44 > To: u-boot@lists.denx.de > Cc: Patrick DELAUNAY ; U-Boot STM32 st...@st-md-mailman.stormreply.com> > Subject: [PATCH 2/4] board: stm32mp1: change dfu function to static > Importance: High > > Change the dfu functions dfu_otp_read and dfu_pmic_read to static, this patch > avoids warning when compiling with W=1. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 4/4] clk: stm32mp1: solve type issue in stm32mp1_lse_enable and stm32mp1_clktree
Hi,
> From: Patrick DELAUNAY
> Sent: mardi 28 janvier 2020 10:44
>
> Solve type issue in stm32mp1_lse_enable and stm32mp1_clktree.
>
> This patch solves the warnings when compiling with W=1 on stm32mp1 board:
>
> clk_stm32mp1.c: In function ‘stm32mp1_lse_enable’:
> clk_stm32mp1.c:1238:15: warning: comparison of integer expressions
> of different signedness: ‘u32’ {aka ‘unsigned int’} and ‘int’
> [-Wsign-compare]
> clk_stm32mp1.c:1239:13: warning: comparison of integer expressions
> of different signedness: ‘u32’ {aka ‘unsigned int’} and ‘int’
> [-Wsign-compare]
>
> clk_stm32mp1.c: In function ‘stm32mp1_clktree’:
> clk_stm32mp1.c:1814:17: warning: comparison of integer expressions
> of different signedness: ‘int’ and ‘unsigned int’
> [-Wsign-compare]
>
> Signed-off-by: Patrick Delaunay
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
RE: [PATCH 1/4] board: stm32mp1: board: add include for dfu
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:44 > > Add include for dfu, add prototype for set_dfu_alt_info and avoid warning when > compiling with W=1. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:11 > > Add support for Rev.Z of STM32MP15x cpu. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 7/9] board: stm32mp1: update readme
Hi,
> From: Patrick DELAUNAY
> Sent: mardi 28 janvier 2020 10:11
>
> Update readme:
> - list the supported SOC and change family to STM32MP15x
> - add warning on OTP write and prerequisite:
> check if MAC address is not yet provisioned.
> - Use filesize for mmc write command (avoid to write all partition
> with ${partsize}). ${filesize} and ${partsize} are set by previous
> load command.
>
> Signed-off-by: Patrick Delaunay
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
RE: [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:11 > > Fix the following DT dtc warnings for stm32mp1 boards: > > Warning (unit_address_vs_reg): /soc/rcc@5000/st,pll@0: > node has a unit name, but no reg property Warning (unit_address_vs_reg): > /soc/rcc@5000/st,pll@1: > node has a unit name, but no reg property Warning (unit_address_vs_reg): > /soc/rcc@5000/st,pll@2: > node has a unit name, but no reg property Warning (unit_address_vs_reg): > /soc/rcc@5000/st,pll@3: > node has a unit name, but no reg property > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:11 > > This patch fix the warning: > dt.dts: Warning (simple_bus_reg): Node /soc/ddr@5A003000 simple-bus unit > address format error, expected "5a003000" > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:11 > > From: Antonio Borneo > > LTDC modifies the clock frequency to adapt it to the display. Such frequency > change is not detected by the FDCAN driver that instead cache the value at > probe > and pretend to use it later. > > Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R. > > Signed-off-by: Antonio Borneo > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:11 > > Device tree and binding alignment with kernel v5.5-rc7 > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
RE: [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:11 > > Device tree and binding alignment with kernel v5.4 > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
Re: i.MX8QXP MEK does not boot
Hi Fabio, On Thu, 13 Feb 2020 15:03:48 -0300 Fabio Estevam feste...@gmail.com wrote: ... > Now it boots U-Boot, but cannot boot the kernel. > > How can we fix this? We have two issues here, power domain off hang reported here [1] and disabling nodes in device tree since commit 9f779fa4105f. [1] https://lists.denx.de/pipermail/u-boot/2020-February/398910.html -- Anatolij
RE: [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr
Hi, > From: Patrick DELAUNAY > Sent: mardi 28 janvier 2020 10:11 > > Update the driver to use the latest binding from kernel v5.5-rc1: > no more use syscon or regmap to access to pwr register and only one > pwr_regulators node with the compatibility "st,stm32mp1,pwr-reg" > is available. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! Regards Patrick
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On 14/02/20 3:31 PM, Anatolij Gustschin wrote:
> On Fri, 14 Feb 2020 09:50:54 +0530
> Lokesh Vutla lokeshvu...@ti.com wrote:
>
>> On 13/02/20 10:42 PM, Neil Armstrong wrote:
>>> Hi,
>>>
>>> On 03/02/2020 14:59, Oliver Graute wrote:
The conga-imx8 board isn't booting without this revert. Can someone tell me
what I need to Do so that this revert is not necessary?
>>
>> Can you give more details on where the failure is happening?(logs would
>> really
>> help).
>
> On i.MX8QXP based SoM running U-Boot v2020.04-rc2 with below patch the
> v4.14.98 kernel from NXP BSP boots:
>
> diff --git a/arch/arm/mach-imx/imx8/fdt.c b/arch/arm/mach-imx/imx8/fdt.c
> index 65c8ac1a7e..cf79a12f42 100644
> --- a/arch/arm/mach-imx/imx8/fdt.c
> +++ b/arch/arm/mach-imx/imx8/fdt.c
> @@ -280,7 +280,9 @@ int ft_system_setup(void *blob, bd_t *bd)
> {
> int ret;
>
> + /*
> update_fdt_with_owned_resources(blob);
> + */
>
> if (is_imx8qm()) {
> ret = config_smmu_fdt(blob);
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index 444e34b492..a218f481b5 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -194,9 +194,18 @@ int device_remove(struct udevice *dev, uint flags)
> }
> }
>
> - if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
> - (dev != gd->cur_serial_dev))
> + if (!(dev->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
> + (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> + (dev != gd->cur_serial_dev)) {
> + dm_warn("%s: OFF '%s', uclass pd %d\n",
> + __func__, dev->name,
> + device_get_uclass_id(dev) == UCLASS_POWER_DOMAIN);
> dev_power_domain_off(dev);
> + } else {
> + dm_warn("%s: '%s', uclass pd %d\n",
> + __func__, dev->name,
> + device_get_uclass_id(dev) == UCLASS_POWER_DOMAIN);
> + }
>
> if (flags_remove(flags, drv->flags)) {
> device_free(dev);
>
> The generated debug log:
>
> Starting kernel ...
>
> device_remove: OFF 'clk', uclass pd 0
> device_remove: OFF 'gpioledsgrp', uclass pd 0
> device_remove: OFF 'lpi2c0grp', uclass pd 0
> device_remove: OFF 'lpi2c1grp', uclass pd 0
> device_remove: OFF 'lpuart2grp', uclass pd 0
> device_remove: OFF 'usdhc1grp', uclass pd 0
> device_remove: OFF 'fec2grp', uclass pd 0
> device_remove: OFF 'imx8qxp-som', uclass pd 0
> device_remove: OFF 'iomuxc', uclass pd 0
> device_remove: OFF 'mu@5d1c', uclass pd 0
> device_remove: 'lsio_gpio0', uclass pd 1
> device_remove: 'lsio_gpio1', uclass pd 1
> device_remove: 'lsio_gpio3', uclass pd 1
> device_remove: 'lsio_gpio4', uclass pd 1
> device_remove: 'lsio_gpio5', uclass pd 1
> device_remove: 'lsio_power_domain', uclass pd 1
> device_remove: 'conn_sdhc0', uclass pd 1
> device_remove: 'conn_enet1', uclass pd 1
> device_remove: 'connectivity_power_domain', uclass pd 1
> device_remove: 'dma_lpi2c0', uclass pd 1
> device_remove: 'dma_lpi2c1', uclass pd 1
> device_remove: 'dma_lpuart2', uclass pd 1
> device_remove: 'dma_power_domain', uclass pd 1
> device_remove: OFF 'imx8qx-pm', uclass pd 0
> device_remove: OFF 'generic_50', uclass pd 0
> device_remove: OFF 'i2c@5a80', uclass pd 0
> device_remove: 'dma_lpi2c0', uclass pd 1
> device_remove: OFF 'i2c@5a81', uclass pd 0
> device_remove: 'dma_lpi2c1', uclass pd 1
> device_remove: OFF 'gpio@5d08', uclass pd 0
> device_remove: 'lsio_gpio0', uclass pd 1
> device_remove: OFF 'gpio@5d09', uclass pd 0
> device_remove: 'lsio_gpio1', uclass pd 1
> device_remove: OFF 'gpio@5d0b', uclass pd 0
> device_remove: 'lsio_gpio3', uclass pd 1
> device_remove: OFF 'gpio@5d0c', uclass pd 0
> device_remove: 'lsio_gpio4', uclass pd 1
> device_remove: OFF 'gpio@5d0d', uclass pd 0
> device_remove: 'lsio_gpio5', uclass pd 1
> device_remove: 'serial@5a08', uclass pd 0
> device_remove: OFF 'us...@5b01.blk', uclass pd 0
> device_remove: OFF 'usdhc@5b01', uclass pd 0
> device_remove: 'conn_sdhc0', uclass pd 1
> device_remove: OFF 'ethernet@5b05', uclass pd 0
> device_remove: 'conn_enet1', uclass pd 1
> device_remove: OFF 'run', uclass pd 0
> device_remove: OFF 'flt', uclass pd 0
> device_remove: OFF 'svc', uclass pd 0
> device_remove: OFF 'com1_tx', uclass pd 0
> device_remove: OFF 'com1_rx', uclass pd 0
> device_remove: OFF 'com2_tx', uclass pd 0
> device_remove: OFF 'com2_rx', uclass pd 0
> device_remove: OFF 'cloud', uclass pd 0
> device_remove: OFF 'wlan', uclass pd 0
> device_remove: OFF 'dbg1', uclass pd 0
> device_remove: OFF 'dbg2', uclass pd 0
> device_remove: OFF 'dbg3', uclass pd 0
> device_remove: OFF 'dbg4', uclass pd 0
> device_remove: OFF 'leds', uclass pd 0
> device_remove: OFF 'root_driver', uclass pd 0
>
> My original patch v3 had this additional condition for power domain off:
>
> (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN)
>
>
[PATCH] arm64: ls1012a: enable DM support for sata
Enable related configs to support sata DM feature. Signed-off-by: Peng Ma --- configs/ls1012a2g5rdb_qspi_defconfig | 1 + configs/ls1012a2g5rdb_tfa_defconfig | 1 + configs/ls1012afrdm_qspi_defconfig | 6 ++ configs/ls1012afrdm_tfa_defconfig| 6 ++ configs/ls1012aqds_tfa_SECURE_BOOT_defconfig | 2 ++ 5 files changed, 16 insertions(+) diff --git a/configs/ls1012a2g5rdb_qspi_defconfig b/configs/ls1012a2g5rdb_qspi_defconfig index b1cf8ef7c5..ae3805ee47 100644 --- a/configs/ls1012a2g5rdb_qspi_defconfig +++ b/configs/ls1012a2g5rdb_qspi_defconfig @@ -35,6 +35,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y +CONFIG_SCSI_AHCI=y CONFIG_SATA_CEVA=y CONFIG_DM_I2C=y CONFIG_DM_MMC=y diff --git a/configs/ls1012a2g5rdb_tfa_defconfig b/configs/ls1012a2g5rdb_tfa_defconfig index a978580952..8e35d0fdfd 100644 --- a/configs/ls1012a2g5rdb_tfa_defconfig +++ b/configs/ls1012a2g5rdb_tfa_defconfig @@ -35,6 +35,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y +CONFIG_SCSI_AHCI=y CONFIG_SATA_CEVA=y CONFIG_DM_I2C=y CONFIG_DM_MMC=y diff --git a/configs/ls1012afrdm_qspi_defconfig b/configs/ls1012afrdm_qspi_defconfig index 11d0cee39a..2aa29deead 100644 --- a/configs/ls1012afrdm_qspi_defconfig +++ b/configs/ls1012afrdm_qspi_defconfig @@ -8,6 +8,7 @@ CONFIG_DM_GPIO=y CONFIG_FSL_LS_PPA=y CONFIG_QSPI_AHB_INIT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y # CONFIG_SYS_MALLOC_F is not set CONFIG_FIT_VERBOSE=y @@ -33,8 +34,11 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y +CONFIG_SCSI_AHCI=y +CONFIG_SATA_CEVA=y CONFIG_DM_I2C=y # CONFIG_MMC is not set +CONFIG_DM_MMC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y # CONFIG_SPI_FLASH_BAR is not set @@ -47,6 +51,8 @@ CONFIG_DM_PCI=y CONFIG_DM_PCI_COMPAT=y CONFIG_PCIE_LAYERSCAPE=y CONFIG_DM_RTC=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y diff --git a/configs/ls1012afrdm_tfa_defconfig b/configs/ls1012afrdm_tfa_defconfig index 2818bdf0d2..30deb771f2 100644 --- a/configs/ls1012afrdm_tfa_defconfig +++ b/configs/ls1012afrdm_tfa_defconfig @@ -10,6 +10,7 @@ CONFIG_QSPI_AHB_INIT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y +CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y # CONFIG_SYS_MALLOC_F is not set CONFIG_FIT_VERBOSE=y @@ -33,8 +34,11 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y +CONFIG_SCSI_AHCI=y +CONFIG_SATA_CEVA=y CONFIG_DM_I2C=y # CONFIG_MMC is not set +CONFIG_DM_MMC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y # CONFIG_SPI_FLASH_BAR is not set @@ -47,6 +51,8 @@ CONFIG_DM_PCI=y CONFIG_DM_PCI_COMPAT=y CONFIG_PCIE_LAYERSCAPE=y CONFIG_DM_RTC=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y diff --git a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig index 23dea4ce23..885a6e0bdf 100644 --- a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig @@ -9,6 +9,7 @@ CONFIG_QSPI_AHB_INIT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y +CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y # CONFIG_SYS_MALLOC_F is not set CONFIG_FIT_VERBOSE=y @@ -38,6 +39,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SCSI_AHCI=y +CONFIG_SATA_CEVA=y CONFIG_DM_I2C=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y -- 2.17.1
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On Fri, 14 Feb 2020 11:01:54 +0100 Anatolij Gustschin ag...@denx.de wrote: ... > My original patch v3 had this additional condition for power domain off: > > (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) The debug log generated without the above condition: device_remove: OFF 'clk', uclass pd 0 device_remove: OFF 'gpioledsgrp', uclass pd 0 device_remove: OFF 'lpi2c0grp', uclass pd 0 device_remove: OFF 'lpi2c1grp', uclass pd 0 device_remove: OFF 'lpuart2grp', uclass pd 0 device_remove: OFF 'usdhc1grp', uclass pd 0 device_remove: OFF 'fec2grp', uclass pd 0 device_remove: OFF 'imx8qxp-som', uclass pd 0 device_remove: OFF 'iomuxc', uclass pd 0 device_remove: OFF 'mu@5d1c', uclass pd 0 device_remove: OFF 'lsio_gpio0', uclass pd 1 device_remove: OFF 'lsio_gpio0', uclass pd 1 device_remove: OFF 'lsio_gpio0', uclass pd 1 device_remove: OFF 'lsio_gpio0', uclass pd 1 device_remove: OFF 'lsio_gpio0', uclass pd 1 device_remove: OFF 'lsio_gpio0', uclass pd 1 device_remove: OFF 'lsio_gpio0', uclass pd 1 device_remove: OFF 'lsio_gpio0', uclass pd 1 ... Here it is stuck in an endless recursion for lsio_gpio0 device remove. -- Anatolij
[PULL] Pull request: u-boot-stm32 u-boot-stm32-20200214
Hi Tom, Please pull the STM32 related patches for u-boot-stm32-20200214 for v2020.04-rc3 With the following changes: - add DH Electronics DHCOM SoM and PDK2 board - DT alignment with kernel v5.5-rc7 for stm32mp1 boards - fix STM32 image format for big endian hosts in mkimage - solve warnings in device tree and code for stm32mp1 boards - remove fdt_high and initrd_high for stm32 and stih boards - add support of STM32MP15x Rev.Z - update stm32mp1 readme CI status: https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2194 Thanks, Patrick The following changes since commit 721d6b594be4dc2d13b61f6afee9e437278d3ddd: Prepare v2020.04-rc2 (2020-02-12 09:30:43 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20200214 for you to fetch changes up to 8ee5e3c81f47b8647ef05219058d260199c51d1b: board: stm32: remove fdt_high and fdt_highinitrd_high (2020-02-13 18:47:00 +0100) - add DH Electronics DHCOM SoM and PDK2 board - DT alignment with kernel v5.5-rc7 for stm32mp1 boards - fix STM32 image format for big endian hosts in mkimage - solve warnings in device tree and code for stm32mp1 boards - remove fdt_high and initrd_high for stm32 and stih boards - add support of STM32MP15x Rev.Z - update stm32mp1 readme Antonio Borneo (2): ARM: dts: stm32mp1: move FDCAN to PLL4_R tools: mkimage: fix STM32 image format for big endian hosts Marek Vasut (1): ARM: dts: stm32: Add DH Electronics DHCOM SoM and PDK2 board Patrice Chotard (3): board: stih410-b2260: remove fdt_high and initrd_high board: stm32: fix extra env setings addresses board: stm32: remove fdt_high and fdt_highinitrd_high Patrick Delaunay (12): ARM: dts: stm32mp1: DT alignment with kernel v5.4 stm32mp1: pwr: use the last binding for pwr ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7 ARM: dts: stm32mp1: correct ddr node ARM: dts: stm32m1: add reg for pll nodes board: stm32mp1: update readme stm32mp1: support of STM32MP15x Rev.Z board: stm32mp1: board: add include for dfu board: stm32mp1: change dfu function to static pinctrl: stmfx: update the result type of dm_i2c_reg_read clk: stm32mp1: solve type issue in stm32mp1_lse_enable and stm32mp1_clktree stm32mp1: remove fdt_high and initrd_high in environment arch/arm/dts/Makefile| 3 +- arch/arm/dts/stm32mp15-ddr.dtsi | 2 +- arch/arm/dts/stm32mp157-pinctrl.dtsi | 31 ++- arch/arm/dts/stm32mp157-u-boot.dtsi | 4 +- arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 10 +- arch/arm/dts/stm32mp157a-avenger96.dts | 11 +- arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 27 +-- arch/arm/dts/stm32mp157a-dk1.dts | 73 +- arch/arm/dts/stm32mp157c-dk2.dts | 13 ++ arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 10 +- arch/arm/dts/stm32mp157c-ed1.dts | 28 ++- arch/arm/dts/stm32mp157c-ev1.dts | 8 +- arch/arm/dts/stm32mp157c.dtsi| 48 ++-- arch/arm/dts/stm32mp15xx-dhcom-pdk2-u-boot.dtsi | 6 + arch/arm/dts/stm32mp15xx-dhcom-pdk2.dts | 88 arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 246 arch/arm/dts/stm32mp15xx-dhcom.dtsi | 377 +++ arch/arm/mach-stm32mp/Kconfig| 9 + arch/arm/mach-stm32mp/cpu.c | 3 + arch/arm/mach-stm32mp/include/mach/stm32.h | 1 - arch/arm/mach-stm32mp/include/mach/sys_proto.h | 1 + arch/arm/mach-stm32mp/pwr_regulator.c| 23 +- arch/arm/mach-stm32mp/syscon.c | 1 - board/dhelectronics/dh_stm32mp1/Kconfig | 21 ++ board/dhelectronics/dh_stm32mp1/MAINTAINERS | 7 + board/dhelectronics/dh_stm32mp1/Makefile | 10 + board/dhelectronics/dh_stm32mp1/board.c | 689 board/st/stm32mp1/README | 52 +++-- board/st/stm32mp1/stm32mp1.c | 5 +- configs/stm32mp15_dhcom_basic_defconfig | 138 doc/device-tree-bindings/clock/st,stm32mp1.txt | 32 ++- doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt | 6 +- drivers/clk/clk_stm32mp1.c | 9 +- drivers/pinctrl/pinctrl-stmfx.c | 7 +- include/configs/stih410-b2260.h | 8 +- include/configs/stm32f429-evaluation.h | 15 +- include/configs/stm32f469-discovery.h| 15 +- include/configs/stm32f746-disco.h| 15 +- include/configs/stm32h743-disco.h| 14 +- include/configs/stm32h743-eval.h
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On Fri, 14 Feb 2020 09:50:54 +0530
Lokesh Vutla lokeshvu...@ti.com wrote:
> On 13/02/20 10:42 PM, Neil Armstrong wrote:
> > Hi,
> >
> > On 03/02/2020 14:59, Oliver Graute wrote:
> >> The conga-imx8 board isn't booting without this revert. Can someone tell me
> >> what I need to Do so that this revert is not necessary?
>
> Can you give more details on where the failure is happening?(logs would really
> help).
On i.MX8QXP based SoM running U-Boot v2020.04-rc2 with below patch the
v4.14.98 kernel from NXP BSP boots:
diff --git a/arch/arm/mach-imx/imx8/fdt.c b/arch/arm/mach-imx/imx8/fdt.c
index 65c8ac1a7e..cf79a12f42 100644
--- a/arch/arm/mach-imx/imx8/fdt.c
+++ b/arch/arm/mach-imx/imx8/fdt.c
@@ -280,7 +280,9 @@ int ft_system_setup(void *blob, bd_t *bd)
{
int ret;
+ /*
update_fdt_with_owned_resources(blob);
+ */
if (is_imx8qm()) {
ret = config_smmu_fdt(blob);
diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
index 444e34b492..a218f481b5 100644
--- a/drivers/core/device-remove.c
+++ b/drivers/core/device-remove.c
@@ -194,9 +194,18 @@ int device_remove(struct udevice *dev, uint flags)
}
}
- if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
- (dev != gd->cur_serial_dev))
+ if (!(dev->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
+ (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
+ (dev != gd->cur_serial_dev)) {
+ dm_warn("%s: OFF '%s', uclass pd %d\n",
+ __func__, dev->name,
+ device_get_uclass_id(dev) == UCLASS_POWER_DOMAIN);
dev_power_domain_off(dev);
+ } else {
+ dm_warn("%s: '%s', uclass pd %d\n",
+ __func__, dev->name,
+ device_get_uclass_id(dev) == UCLASS_POWER_DOMAIN);
+ }
if (flags_remove(flags, drv->flags)) {
device_free(dev);
The generated debug log:
Starting kernel ...
device_remove: OFF 'clk', uclass pd 0
device_remove: OFF 'gpioledsgrp', uclass pd 0
device_remove: OFF 'lpi2c0grp', uclass pd 0
device_remove: OFF 'lpi2c1grp', uclass pd 0
device_remove: OFF 'lpuart2grp', uclass pd 0
device_remove: OFF 'usdhc1grp', uclass pd 0
device_remove: OFF 'fec2grp', uclass pd 0
device_remove: OFF 'imx8qxp-som', uclass pd 0
device_remove: OFF 'iomuxc', uclass pd 0
device_remove: OFF 'mu@5d1c', uclass pd 0
device_remove: 'lsio_gpio0', uclass pd 1
device_remove: 'lsio_gpio1', uclass pd 1
device_remove: 'lsio_gpio3', uclass pd 1
device_remove: 'lsio_gpio4', uclass pd 1
device_remove: 'lsio_gpio5', uclass pd 1
device_remove: 'lsio_power_domain', uclass pd 1
device_remove: 'conn_sdhc0', uclass pd 1
device_remove: 'conn_enet1', uclass pd 1
device_remove: 'connectivity_power_domain', uclass pd 1
device_remove: 'dma_lpi2c0', uclass pd 1
device_remove: 'dma_lpi2c1', uclass pd 1
device_remove: 'dma_lpuart2', uclass pd 1
device_remove: 'dma_power_domain', uclass pd 1
device_remove: OFF 'imx8qx-pm', uclass pd 0
device_remove: OFF 'generic_50', uclass pd 0
device_remove: OFF 'i2c@5a80', uclass pd 0
device_remove: 'dma_lpi2c0', uclass pd 1
device_remove: OFF 'i2c@5a81', uclass pd 0
device_remove: 'dma_lpi2c1', uclass pd 1
device_remove: OFF 'gpio@5d08', uclass pd 0
device_remove: 'lsio_gpio0', uclass pd 1
device_remove: OFF 'gpio@5d09', uclass pd 0
device_remove: 'lsio_gpio1', uclass pd 1
device_remove: OFF 'gpio@5d0b', uclass pd 0
device_remove: 'lsio_gpio3', uclass pd 1
device_remove: OFF 'gpio@5d0c', uclass pd 0
device_remove: 'lsio_gpio4', uclass pd 1
device_remove: OFF 'gpio@5d0d', uclass pd 0
device_remove: 'lsio_gpio5', uclass pd 1
device_remove: 'serial@5a08', uclass pd 0
device_remove: OFF 'us...@5b01.blk', uclass pd 0
device_remove: OFF 'usdhc@5b01', uclass pd 0
device_remove: 'conn_sdhc0', uclass pd 1
device_remove: OFF 'ethernet@5b05', uclass pd 0
device_remove: 'conn_enet1', uclass pd 1
device_remove: OFF 'run', uclass pd 0
device_remove: OFF 'flt', uclass pd 0
device_remove: OFF 'svc', uclass pd 0
device_remove: OFF 'com1_tx', uclass pd 0
device_remove: OFF 'com1_rx', uclass pd 0
device_remove: OFF 'com2_tx', uclass pd 0
device_remove: OFF 'com2_rx', uclass pd 0
device_remove: OFF 'cloud', uclass pd 0
device_remove: OFF 'wlan', uclass pd 0
device_remove: OFF 'dbg1', uclass pd 0
device_remove: OFF 'dbg2', uclass pd 0
device_remove: OFF 'dbg3', uclass pd 0
device_remove: OFF 'dbg4', uclass pd 0
device_remove: OFF 'leds', uclass pd 0
device_remove: OFF 'root_driver', uclass pd 0
My original patch v3 had this additional condition for power domain off:
(device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN)
This was dropped in the merged patch for some reason, I don't know why.
--
Anatolij
Re: [u-boot PATCH] board: ti: am57xx-idk: Prevent boot for invalid configuation
On 10/02/20 3:29 PM, Roger Quadros wrote: > On am571x-idk there can be following configurations based on Jumper J51 > and LCD panel detected. > > 1) J51 removed (6port): 6 port Ethernet. Disable LCD panel. > 2) J51 placed (LCD) + Panel detected: 4 port Ethernet with appropriate LCD. > 3) J51 placed (LCD) + Panel not detected/not supported. > > Configuration 3 is considered invalid as we can't use display nor ICSS1 > ethernet ports due to hardware muxing. Alert the user to fix the > configuration and prevent boot. > > Alternative was to allow boot and limit to 4 port Ethernet with no display > but this involved introduction of another DTB for the kernel and was > considered not worth the hassle. > > Signed-off-by: Roger Quadros > Acked-by: Suman Anna Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [PATCH] ARM: keystone2: enable initrd fixup for LPAE addressing
On 11/02/20 9:25 AM, Lokesh Vutla wrote: > From: Tero Kristo > > Keystone2 u-boot loads the initrd image into non-LPAE addressed memory > but linux kernel is running in LPAE. This causes a conflict as kernel > detects that non-memory address is passed and kernel ignores initrd. > There is an existing fixup logic to modify the address in the proper > configuration, but this is disabled at the moment. Enable the fixup > by setting the env variable for this so that initrd can be used > properly. > > Signed-off-by: Tero Kristo > Signed-off-by: Lokesh Vutla Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [PATCH] arm: mach-k3: Fix nomenclature on Silicon Revisions
On 10/02/20 10:39 AM, Lokesh Vutla wrote: > Data manual mentions the new silicon revisions as SR instead of PG. Use > the same nomenclature inside U-Boot as well. > > Signed-off-by: Lokesh Vutla Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [PATCH] arm: K3: j721e: Fix boot parameter table index memory address
On 12/02/20 10:23 AM, Lokesh Vutla wrote: > From: Andreas Dannenberg > > The boot parameter table index memory address for J721E was configured > to an incorrect value which prevented the use of this definition to > determine which boot parameter table is active which is needed to be > able to distinguish between primary and backup boot modes. Fix this > issue by updating the value to the correct one also in alignment with > the J721E Technical Reference Manual (TRM). > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [PATCH] armV7R: K3: am654: Activate early console functionality
On 12/02/20 10:24 AM, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Activate early console functionality on AM65x devices to allow for > early diagnostic messages until the main console is ready > to get activated. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [PATCH 0/2] Fix usb host boot mode in AM437x-gp-evm
On 06/02/20 3:22 PM, Faiz Abbas wrote: > The following patches fix usb host boot mode in am437x-gp-evm. Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [PATCH 0/2] Fix Ethernet boot in am437x-evm
On 31/01/20 3:23 PM, Faiz Abbas wrote: > The following patches fix ethernet boot in am437x-evm. Merged into u-boot-ti. Thanks and regards, Lokesh
[GIT PULL] TI changes for v2020.04-rc3
Hi Tom, Please find the pull request for v2020.04-rc3 containing TI specific changes. Travis-CI build: https://travis-ci.org/lokeshvutla/u-boot/builds/650270755 Thanks and regards, Lokesh The following changes since commit 01e7a40e395aefea94e9fb943b9447f7d0fd7efa: Merge tag 'arc-fixes-for-2020.04-rc2' of https://gitlab.denx.de/u-boot/custodians/u-boot-arc (2020-02-12 17:20:25 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.04-rc3 for you to fetch changes up to 96dd223c2933a9190411f52ab0654f50feca3005: armV7R: K3: am654: Activate early console functionality (2020-02-13 21:39:18 +0530) Below are the major changes in this PR: K3 J721E/AM65X: - UART boot fixes for J721E - Enabling debug uart for AM65x DRA7xx/AM57xx: - Preveinting boot from Invalid boot configuration for AM57xx Keysonte2: - Linux Boot fixes for K2 platforms. AM33/AM43/Davinci: - Ethernt boot fixes for AM43XX - USB Host boot fixes for AM43XX Andreas Dannenberg (2): arm: K3: j721e: Fix boot parameter table index memory address armV7R: K3: am654: Activate early console functionality Faiz Abbas (4): arm: dts: am437x-gp-evm: Add some nodes to u-boot.dtsi configs: am43xx_evm: Enable SPL_ETH_SUPPORT configs: am43xx_evm_usbhost: Add configs for USB Host boot mode configs: am43xx_evm_usbhost_boot: Add device for environment Lokesh Vutla (3): arm: dts: k3-j721e-r5-common-proc-board: Disable power-domains for mcu uart configs: j721e_evm_r5: Enable early cons arm: mach-k3: Fix nomenclature on Silicon Revisions Roger Quadros (1): board: ti: am57xx-idk: Prevent boot for invalid configuation Tero Kristo (1): ARM: keystone2: enable initrd fixup for LPAE addressing arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 16 arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 4 arch/arm/mach-k3/Kconfig | 2 +- arch/arm/mach-k3/am6_init.c| 10 ++ arch/arm/mach-k3/common.c | 2 +- board/ti/am57xx/board.c| 13 + configs/am43xx_evm_defconfig | 1 + configs/am43xx_evm_usbhost_boot_defconfig | 12 configs/j721e_evm_r5_defconfig | 1 + include/configs/ti_armv7_keystone2.h | 1 + 10 files changed, 60 insertions(+), 2 deletions(-) -- 2.23.0
Re: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
On 13. 02. 20 18:48, Tom Rini wrote: > On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote: >> >> >>> Am 13.02.2020 um 16:01 schrieb Tom Rini : >>> >>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote: >>> From: Jens Rehsack Introduce SUPPLIER analogous to VENDOR to allow (from customer perspective) a VENDOR using it's SUPPLIER's common/ code. This is reasonable, when a VENDOR (from customer perspective) builds several machines sharing some features (e.g. some FPGA which has to be initialized during u-boot) but wants to use common NXP or Samsung code for the BSP instead of copying and create merge overhead. Signed-off-by: Jens Rehsack --- Makefile | 4 +++- arch/Kconfig | 12 config.mk| 6 +- 3 files changed, 20 insertions(+), 2 deletions(-) >>> >>> Can you provide a follow-up where this it clearer / easier to do >>> something than today? Thanks! >> >> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common >> NXP code for the Management Complex is needed. I2C code either - this >> covers board/freescale/common/... >> >> Given you build machines from there with different SoCs under a >> new label - let's call it SuperLink, so you have >> * board/freescale/common >> * board/superlink/common >> * board/superlink/legacy-tune <-- based on some PowerPC >> * board/superlink/easy-tune <-- based on LS2088 >> * board/superlink/heavy-tune <-- based on LX2160 >> >> All *-tune machines the customer buys from SuperLink have a >> similar FPGA (there is a little bit more, but for the vision >> it's probably better to stay small) and a similar external >> PMIC/BMC. >> >> But SuperLink still uses code from board/freescale/common (their >> supplier) and it's not reasonable to copy those. >> >> I rate all this not suitable for a commit message. How do >> you suggest to proceed? > > Well, lets add in Michal as there are Zynq examples that could be > cleaned up with what you're proposing. Similarly, Vanessa and Otavio > might have thoughts here as they could rework some of the TechNexion > boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved > from board/ to some sub-directory?). Thanks all! I think it will be the best to take any of your example and simply create a series where this is applied to see if that code looks better then before. Applying this without usage doesn't make sense. For zynq there are some boards like topic, bitmain, opalkelly which are staying in own folder but sourcing zynq board.c. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On 14/02/20 2:48 PM, Oliver Graute wrote: > On 14/02/20, Lokesh Vutla wrote: >> >> >> On 13/02/20 10:42 PM, Neil Armstrong wrote: >>> Hi, >>> >>> On 03/02/2020 14:59, Oliver Graute wrote: The conga-imx8 board isn't booting without this revert. Can someone tell me what I need to Do so that this revert is not necessary? >> >> Can you give more details on where the failure is happening?(logs would >> really >> help). > > without that revert patch u-boot is stuck at "Starting kernel ..." > Is there a way to get more details here? currently I don't know howto > debug that power-domain stuff deeper. Can you enable debug prints in: - drivers/power/domain/power-domain-uclass.c - drivers/power/domain/imx8-power-domain*.c and provide the logs? this will help which power-domain is causing the issue. Thanks and regards, Lokesh > > Bytes transferred = 27030016 (19c7200 hex) > Using ethernet@5b04 device > TFTP from server 10.200.134.119; our IP address is 10.200.134.121 > Filename 'imx8qm-cgt-qmx8.dtb'. > Load address: 0x8300 > Loading: # > 2.5 MiB/s > done > Bytes transferred = 21224 (52e8 hex) > ## Flattened Device Tree blob at 8300 >Booting using the fdt blob at 0x8300 >Using Device Tree in place at 8300, end 830082e7 > > Starting kernel ... > > Best regards, > > Oliver >
Antwort: Re: [PATCH 009/108] x86: apl: Move p2sb ofdata reading to the correct method
Hello Bin, Simon, -"Bin Meng" schrieb: - > +Wolfgang Wallner > > On Mon, Jan 27, 2020 at 1:08 PM Simon Glass wrote: > > > > With P2SB the initial BAR (base-address register) is set up by TPL and > > this is used unchanged right through U-Boot. > > > > At present the reading of this address is split between the ofdata() and > > probe() methods. There are a few problems that are unique to the p2sb. > > One is that its children need to call pcr_read32(), etc. which needs to > > have the p2sb address correct. Also some of its children are pinctrl > > devices and pinctrl is used when any device is probed. So p2sb really > > needs to get its base address set up in ofdata_to_platdata(), before it is > > probed. > > > > Another point is that reading the p2sb BAR will not work if the p2sb is > > hidden. The FSP-S seems to hide it, presumably to avoid confusing PCI > > enumeration. > > > > Reading ofdata in ofdata_to_platdata() is the correct place anyway, so > > this is easy to fix. > > > > Move the code into one place and use the early-regs property in all cases > > for simplicity and to avoid needing to probe any PCI devices just to read > > the BAR. > > > > Signed-off-by: Simon Glass > > --- > > > > arch/x86/cpu/apollolake/p2sb.c | 33 +++-- > > 1 file changed, 11 insertions(+), 22 deletions(-) > > > > I think this one needs to be rebased. > > I suspect it breaks Wolfgang's use case. Wolfgang, any comments? Thanks for pointing this out. As far as I understand, the patch changes the following for my use case (Coreboot + U-Boot, no TPL and no SPL): * Before: plat->mmio_base was read from the PCI BAR in apl_p2sb_probe() * After: plat->mmio_base is read from the "early-regs" device tree property in apl_p2sb_ofdata_to_platdata() I think this is fine, Coreboot does not change the address in BAR0 and I can use the "early-regs" property in my device tree. regards, Wolfgang Reviewed-by: Wolfgang Wallner Tested-by: Wolfgang Wallner Tested on an Apollo Lake board with Coreboot + U-Boot.
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On 14/02/20, Lokesh Vutla wrote: > > > On 13/02/20 10:42 PM, Neil Armstrong wrote: > > Hi, > > > > On 03/02/2020 14:59, Oliver Graute wrote: > >> The conga-imx8 board isn't booting without this revert. Can someone tell me > >> what I need to Do so that this revert is not necessary? > > Can you give more details on where the failure is happening?(logs would really > help). without that revert patch u-boot is stuck at "Starting kernel ..." Is there a way to get more details here? currently I don't know howto debug that power-domain stuff deeper. Bytes transferred = 27030016 (19c7200 hex) Using ethernet@5b04 device TFTP from server 10.200.134.119; our IP address is 10.200.134.121 Filename 'imx8qm-cgt-qmx8.dtb'. Load address: 0x8300 Loading: # 2.5 MiB/s done Bytes transferred = 21224 (52e8 hex) ## Flattened Device Tree blob at 8300 Booting using the fdt blob at 0x8300 Using Device Tree in place at 8300, end 830082e7 Starting kernel ... Best regards, Oliver
[PATCHv2 7/7] configs: j721e_evm_r5_defconfig: Enable ESM modules
Enable ESM modules for both PMIC and SoC side for proper watchdog handling on the board. SPL_BOARD_INIT is also enabled so that the board init function probing the drivers is called. Signed-off-by: Tero Kristo --- configs/j721e_evm_r5_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index 19fbd450c7..a28ea30372 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -122,3 +122,6 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6163 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_FS_EXT4=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 +CONFIG_ESM_K3=y +CONFIG_ESM_PMIC=y +CONFIG_SPL_BOARD_INIT=y -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
