Re: [U-Boot] [PATCH 2/2] arm: socfpga: gen5: don't zero bss in board_init_f()
On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote: > > On 7/11/19 9:18 PM, Simon Goldschmidt wrote: > > The socfpga gen5 SPL manually zeroed bss in board_init_f(). Now that the > > DDR driver does not use bss any more, bss is not used before board_init_r() > > and we can remove this hack. > > > > Signed-off-by: Simon Goldschmidt > > --- > > > > arch/arm/mach-socfpga/spl_gen5.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/arch/arm/mach-socfpga/spl_gen5.c > > b/arch/arm/mach-socfpga/spl_gen5.c > > index 87b76b47de..47e63709ad 100644 > > --- a/arch/arm/mach-socfpga/spl_gen5.c > > +++ b/arch/arm/mach-socfpga/spl_gen5.c > > @@ -79,8 +79,6 @@ void board_init_f(ulong dummy) > > writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN, > > _regs->eccgrp_ocram); > > > > - memset(__bss_start, 0, __bss_end - __bss_start); > > - > > socfpga_sdram_remap_zero(); > > socfpga_pl310_clear(); > > So who will zero out the BSS ? BSS is zeroed by crt0.S, but after board_init_f(), before board_init_r(). Socfpga just had this double-zeroing because it invalidly used BSS in board_init_f(). Some weeks ago on this list, we've had a discussion whether it would be good to generally allow such early usage of BSS, possibly via a config option (socfpga is not the only platform affected). The outcome was negative and so I've started this patch. Regards, Simon > > [...] ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: do not reboot via SRAM
On 7/12/19 7:20 AM, Simon Goldschmidt wrote:
> On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote:
>>
>> On 7/10/19 9:06 PM, Simon Goldschmidt wrote:
>>> This removes the code that enables the Boot ROM to just jump to SRAM
>>> instead of loading SPL from the original boot source on warm reboot.
>>>
>>> The reason for removing this is that it is insecure: SRAM might be
>>> overwritten at the time the warm reboot is done. Instead, use the default
>>> behaviour of loading SPL from the configured boot source medium.
>>>
>>> Signed-off-by: Simon Goldschmidt
>>> ---
>>>
>>> Changes in v2:
>>> - remove the compatibility code restoring the old "reboot from SRAM"
>>> behaviour via an env var callback as it turned out such a hack should
>>> not be included by default
>>> - (v1 patch subject was: "arm: socfpga: control reboot from SRAM via env
>>> callback")
>>>
>>> arch/arm/mach-socfpga/misc_gen5.c | 10 +-
>>> 1 file changed, 1 insertion(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
>>> b/arch/arm/mach-socfpga/misc_gen5.c
>>> index 71547d81ab..38bff8a450 100644
>>> --- a/arch/arm/mach-socfpga/misc_gen5.c
>>> +++ b/arch/arm/mach-socfpga/misc_gen5.c
>>> @@ -6,6 +6,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -182,15 +183,6 @@ int arch_early_init_r(void)
>>> {
>>> int i;
>>>
>>> - /*
>>> - * Write magic value into magic register to unlock support for
>>> - * issuing warm reset. The ancient kernel code expects this
>>> - * value to be written into the register by the bootloader, so
>>> - * to support that old code, we write it here instead of in the
>>> - * reset_cpu() function just before resetting the CPU.
>>> - */
>>> - writel(0xae9efebc, _regs->romcodegrp_warmramgrp_enable);
>>
>> Does this break ancient altera kernel versions ? Do we care ?
>
> You mean ancient kernels built from non-mainline sources? I don't really care,
> no.
>
> However, this *might* break boards like my older hw revisions that set qspi
> into
> four byte mode. But given that, depending on the situation, those *are*
> already
> broken, I think removing this code is still the correct thing to do.
>
> The bonus is that you'll notice on the very first try that 'reboot' doesn't
> work. Whereas before,t it worked at the start and then might break in some
> specific situation you'll not be able to test.
Does reboot still work in mainline Linux with this ?
I am somewhat reluctant to apply this patch, since I recall there was
some weird reason this write was added, but I don't remember what it was.
--
Best regards,
Marek Vasut
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-56 Email: ma...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote: > > On 7/10/19 9:22 PM, Simon Goldschmidt wrote: > > Am 09.05.2019 um 21:53 schrieb Marek Vasut: > >> On 5/9/19 8:55 PM, Simon Goldschmidt wrote: > >>> > >>> > >>> On 09.05.19 20:08, Simon Goldschmidt wrote: > This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v3: > - moved socfpga gen5 sysreset driver to extra patch > > Changes in v2: None > > drivers/sysreset/Kconfig| 7 > drivers/sysreset/Makefile | 1 + > drivers/sysreset/sysreset_socfpga.c | 56 > + > 3 files changed, 64 insertions(+) > create mode 100644 drivers/sysreset/sysreset_socfpga.c > >>> > >>> I just noticed patman complained about new files regarding MAINTAINERS. > >>> Should these new drivers be listed in the MAINTAINERS file under the > >>> socfpga section? I noticed other platforms seem to do that but we don't. > >>> How is this handled? > >> > >> I think that's sane. > > > > Sorry for the delay of nearly two months, but what did you mean by this? > > Add the files to MAINTAINERS? > > I think so. Right, I think so, too. Just was reluctant as it was the first being added there... Thanks, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: do not reboot via SRAM
On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote:
>
> On 7/10/19 9:06 PM, Simon Goldschmidt wrote:
> > This removes the code that enables the Boot ROM to just jump to SRAM
> > instead of loading SPL from the original boot source on warm reboot.
> >
> > The reason for removing this is that it is insecure: SRAM might be
> > overwritten at the time the warm reboot is done. Instead, use the default
> > behaviour of loading SPL from the configured boot source medium.
> >
> > Signed-off-by: Simon Goldschmidt
> > ---
> >
> > Changes in v2:
> > - remove the compatibility code restoring the old "reboot from SRAM"
> > behaviour via an env var callback as it turned out such a hack should
> > not be included by default
> > - (v1 patch subject was: "arm: socfpga: control reboot from SRAM via env
> > callback")
> >
> > arch/arm/mach-socfpga/misc_gen5.c | 10 +-
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/misc_gen5.c
> > b/arch/arm/mach-socfpga/misc_gen5.c
> > index 71547d81ab..38bff8a450 100644
> > --- a/arch/arm/mach-socfpga/misc_gen5.c
> > +++ b/arch/arm/mach-socfpga/misc_gen5.c
> > @@ -6,6 +6,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -182,15 +183,6 @@ int arch_early_init_r(void)
> > {
> > int i;
> >
> > - /*
> > - * Write magic value into magic register to unlock support for
> > - * issuing warm reset. The ancient kernel code expects this
> > - * value to be written into the register by the bootloader, so
> > - * to support that old code, we write it here instead of in the
> > - * reset_cpu() function just before resetting the CPU.
> > - */
> > - writel(0xae9efebc, _regs->romcodegrp_warmramgrp_enable);
>
> Does this break ancient altera kernel versions ? Do we care ?
You mean ancient kernels built from non-mainline sources? I don't really care,
no.
However, this *might* break boards like my older hw revisions that set qspi into
four byte mode. But given that, depending on the situation, those *are* already
broken, I think removing this code is still the correct thing to do.
The bonus is that you'll notice on the very first try that 'reboot' doesn't
work. Whereas before,t it worked at the start and then might break in some
specific situation you'll not be able to test.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: socfpga: gen5: don't zero bss in board_init_f()
On 7/11/19 9:18 PM, Simon Goldschmidt wrote: > The socfpga gen5 SPL manually zeroed bss in board_init_f(). Now that the > DDR driver does not use bss any more, bss is not used before board_init_r() > and we can remove this hack. > > Signed-off-by: Simon Goldschmidt > --- > > arch/arm/mach-socfpga/spl_gen5.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/mach-socfpga/spl_gen5.c > b/arch/arm/mach-socfpga/spl_gen5.c > index 87b76b47de..47e63709ad 100644 > --- a/arch/arm/mach-socfpga/spl_gen5.c > +++ b/arch/arm/mach-socfpga/spl_gen5.c > @@ -79,8 +79,6 @@ void board_init_f(ulong dummy) > writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN, > _regs->eccgrp_ocram); > > - memset(__bss_start, 0, __bss_end - __bss_start); > - > socfpga_sdram_remap_zero(); > socfpga_pl310_clear(); So who will zero out the BSS ? [...] ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: ddr: socfpga: fix gen5 ddr driver to not use bss
On 7/11/19 9:18 PM, Simon Goldschmidt wrote: > This driver uses bss from SPL board_init_f(). Change it to move all the > data from bss to a common struct allocated on the stack (64 byte). > > In addition to saving 28 bytes of bss, the code even gets 264 bytes > smaller. > > Signed-off-by: Simon Goldschmidt Applied, thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
On 7/10/19 10:09 PM, Simon Goldschmidt wrote:
> This fixes 3 boards that don't use CONFIG_EXTRA_ENV_SETTINGS from
> socfpga_common.h. They need to enable reset manager compatibility
> mode unless all peripheral drivers in Linux support reset handling.
>
> Fixes: commit 4b2e32efa4e7 ("arm: socfpga: gen5: deassert peripheral reset by
> default")
> Signed-off-by: Simon Goldschmidt
> Reported-by: Wolfgang Grandegger
Applied, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] usb_kdb: only process events succesfully received
On 7/10/19 5:47 PM, Michal Suchánek wrote: > On Fri, 5 Jul 2019 14:12:36 +0200 > Marek Vasut wrote: > >> On 7/5/19 12:44 PM, Michal Suchanek wrote: >>> Causes unbound key repeat on error otherwise. >>> >>> Signed-off-by: Michal Suchanek >>> --- >>> v2: fix indentation >> >> What changed in V3 ? >> >>> --- >>> common/usb_kbd.c | 7 +++ >>> 1 file changed, 3 insertions(+), 4 deletions(-) >>> >>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c >>> index cc99c6be0720..fc9419e0238a 100644 >>> --- a/common/usb_kbd.c >>> +++ b/common/usb_kbd.c >>> @@ -339,10 +339,9 @@ static inline void usb_kbd_poll_for_event(struct >>> usb_device *dev) >>> struct usb_kbd_pdata *data = dev->privptr; >>> >>> /* Submit a interrupt transfer request */ >>> - usb_submit_int_msg(dev, data->intpipe, >new[0], data->intpktsize, >>> - data->intinterval); >>> - >>> - usb_kbd_irq_worker(dev); >>> + if (!usb_submit_int_msg(dev, data->intpipe, >new[0], >>> + data->intpktsize, data->intinterval)) >> >> This still doesn't propagate errors. > > Yes, it does not. I don't have a grand design that would make use of > these propagated errors so I don't know what errors to propagate. Each and every called of usb_kbd_poll_for_event() returns some return value, so these functions should at least be aware of the new errors which might come from usb_kbd_poll_for_event(). > You could, say, want to propagate errors from kbd_irq_worker as well. > > Until there is a way to make use of the errors you really don't know. > > Might be good idea to document that getting EAGAIN from > usb_int_msg_nonblock is expected. [...] ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] usb: add usb_int_msg_nonblock
On 7/10/19 5:52 PM, Michal Suchánek wrote:
> On Fri, 5 Jul 2019 14:13:50 +0200
> Marek Vasut wrote:
>
>> On 7/5/19 12:44 PM, Michal Suchanek wrote:
>>> Variant of the int_msg wrapper that does not introduce excessive retry
>>> delay on error.
>>>
>>> Signed-off-by: Michal Suchanek
>>> ---
>>> v2: usb_submit_int_msg -> usb_int_msg
>>> ---
>>> common/usb.c | 9 +
>>> include/usb.h | 2 ++
>>> 2 files changed, 11 insertions(+)
>>>
>>> diff --git a/common/usb.c b/common/usb.c
>>> index f57c0e8cdf57..1bd60b24a555 100644
>>> --- a/common/usb.c
>>> +++ b/common/usb.c
>>> @@ -200,6 +200,15 @@ int usb_int_msg(struct usb_device *dev, unsigned long
>>> pipe,
>>> return submit_int_msg(dev, pipe, buffer, transfer_len, interval, false);
>>> }
>>>
>>> +/*
>>> + * submits an Interrupt Message without retry
>>> + */
>>> +int usb_int_msg_nonblock(struct usb_device *dev, unsigned long pipe,
>>> + void *buffer, int transfer_len, int interval)
>>> +{
>>> + return submit_int_msg(dev, pipe, buffer, transfer_len, interval, true);
>>> +}
>>
>> Wouldn't it be shorter to just call submit_int_msg() directly, with the
>> extra parameter ?
>
> It is easier to understand the change this way. The idea is that only
> some very specific callers need to know about the difference.
It's just another layer of meaningless obfuscation. Explain what the
parameter does in a comment and be done with it.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On 7/10/19 9:22 PM, Simon Goldschmidt wrote: > Am 09.05.2019 um 21:53 schrieb Marek Vasut: >> On 5/9/19 8:55 PM, Simon Goldschmidt wrote: >>> >>> >>> On 09.05.19 20:08, Simon Goldschmidt wrote: This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5. Signed-off-by: Simon Goldschmidt --- Changes in v3: - moved socfpga gen5 sysreset driver to extra patch Changes in v2: None drivers/sysreset/Kconfig | 7 drivers/sysreset/Makefile | 1 + drivers/sysreset/sysreset_socfpga.c | 56 + 3 files changed, 64 insertions(+) create mode 100644 drivers/sysreset/sysreset_socfpga.c >>> >>> I just noticed patman complained about new files regarding MAINTAINERS. >>> Should these new drivers be listed in the MAINTAINERS file under the >>> socfpga section? I noticed other platforms seem to do that but we don't. >>> How is this handled? >> >> I think that's sane. > > Sorry for the delay of nearly two months, but what did you mean by this? > Add the files to MAINTAINERS? I think so. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: do not reboot via SRAM
On 7/10/19 9:06 PM, Simon Goldschmidt wrote:
> This removes the code that enables the Boot ROM to just jump to SRAM
> instead of loading SPL from the original boot source on warm reboot.
>
> The reason for removing this is that it is insecure: SRAM might be
> overwritten at the time the warm reboot is done. Instead, use the default
> behaviour of loading SPL from the configured boot source medium.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v2:
> - remove the compatibility code restoring the old "reboot from SRAM"
> behaviour via an env var callback as it turned out such a hack should
> not be included by default
> - (v1 patch subject was: "arm: socfpga: control reboot from SRAM via env
> callback")
>
> arch/arm/mach-socfpga/misc_gen5.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
> b/arch/arm/mach-socfpga/misc_gen5.c
> index 71547d81ab..38bff8a450 100644
> --- a/arch/arm/mach-socfpga/misc_gen5.c
> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -182,15 +183,6 @@ int arch_early_init_r(void)
> {
> int i;
>
> - /*
> - * Write magic value into magic register to unlock support for
> - * issuing warm reset. The ancient kernel code expects this
> - * value to be written into the register by the bootloader, so
> - * to support that old code, we write it here instead of in the
> - * reset_cpu() function just before resetting the CPU.
> - */
> - writel(0xae9efebc, _regs->romcodegrp_warmramgrp_enable);
Does this break ancient altera kernel versions ? Do we care ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/3] usb: musb-new: Add support for da8xx-musb
On 7/10/19 8:59 PM, Adam Ford wrote: > With the recently added phy driver, this patch will enable the > musb driver on the da8xx to operate in host mode. > > Signed-off-by: Adam Ford > --- > drivers/usb/musb-new/Kconfig | 8 + > drivers/usb/musb-new/Makefile | 1 + > drivers/usb/musb-new/da8xx.c | 350 ++ > 3 files changed, 359 insertions(+) Much better, Reviewed-by: Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] watchdog: Split WDT from SPL_WDT
On 02/07/19 01:55, Marek Vasut wrote: > On 7/1/19 8:45 AM, Suniel Mahesh wrote: >> Hi Marek, >> >> May I know if this patch series is still under review ? > > I guess Stefano is taking them for next ... or ? > Hi Marek/Stefano, Because of this entry "Make SPL_WATCHDOG_SUPPORT imply SPL_WDT if !HW_WATCHDOG", SPL_WDT is getting enabled by default, when board configuration is done. For AM335X based beaglebone black, we dont need SPL_WDT, as the built image is getting too big to fit into SRAM. Is it fine if I disable SPL_WDT in board defconfig file ? used the following entry in defconfig # CONFIG_SPL_WDT is not set (couldn't find a proper place to disable it, except in defconfig) with this the build is fine and board boots. Tested on the beaglebone black board. Tested-by: Suniel Mahesh Thanks Sunil ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm: dts: Add devicetree support for iMXQXP AI_ML board
> Subject: [PATCH v2 1/2] arm: dts: Add devicetree support for iMXQXP AI_ML
> board
>
> Add devicetree support for iMXQXP AI_ML board from Einfochips.
>
> Signed-off-by: Manivannan Sadhasivam
>
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi | 117 +
> arch/arm/dts/fsl-imx8qxp-ai_ml.dts | 181
> +
> 3 files changed, 299 insertions(+)
> create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
> create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> e6680e5e98..7834a158da 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -614,6 +614,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
> dtb-$(CONFIG_ARCH_IMX8) += \
> fsl-imx8qm-apalis.dtb \
> fsl-imx8qm-mek.dtb \
> + fsl-imx8qxp-ai_ml.dtb \
> fsl-imx8qxp-colibri.dtb \
> fsl-imx8qxp-mek.dtb
>
> diff --git a/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
> b/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
> new file mode 100644
> index 00..3ca53bb945
> --- /dev/null
> +++ b/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 Linaro Ltd.
> + */
> +
> +&{/imx8qx-pm} {
> +
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_lsio {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio0 {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio1 {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio2 {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio3 {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio4 {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio5 {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio6 {
> + u-boot,dm-spl;
> +};
> +
> +_lsio_gpio7 {
> + u-boot,dm-spl;
> +};
> +
> +_conn {
> + u-boot,dm-spl;
> +};
> +
> +_conn_sdch0 {
> + u-boot,dm-spl;
> +};
> +
> +_conn_sdch1 {
> + u-boot,dm-spl;
> +};
> +
> +_conn_sdch2 {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
> b/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
> new file mode 100644
> index 00..aa85caaff5
> --- /dev/null
> +++ b/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
> @@ -0,0 +1,181 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018 Einfochips
> + * Copyright 2019 Linaro Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-imx8qxp.dtsi"
> +#include "fsl-imx8qxp-ai_ml-u-boot.dtsi"
> +
> +/ {
> + model = "Einfochips i.MX8QXP AI_ML";
> + compatible = "einfochips,imx8qxp-ai_ml", "fsl,imx8qxp";
> +
> + chosen {
> + bootargs = "console=ttyLP2,115200
> earlycon=lpuart32,0x5a08,115200";
> + stdout-path =
> + };
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x 0x8000 0 0x8000>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_lpuart0>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_lpuart1>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_lpuart2>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_lpuart3>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_fec1>;
> + phy-mode = "rgmii";
> + phy-handle = <>;
> + fsl,ar8031-phy-fixup;
> + fsl,magic-packet;
> + phy-reset-gpios = < 14 GPIO_ACTIVE_LOW>;
> + phy-reset-duration = <10>;
> + phy-reset-post-delay = <150>;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
> + };
> +};
> +
> +/* LS-I2C1 */
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <10>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_lpi2c1>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_usdhc1>;
> + bus-width = <4>;
> + no-sd;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_usdhc2>;
> + bus-width = <4>;
> + cd-gpios = < 22
Re: [U-Boot] [PATCH v2 2/2] board: Add support for iMXQXP AI_ML board
> Subject: [PATCH v2 2/2] board: Add support for iMXQXP AI_ML board > > This commit adds initial board support for iMXQXP AI_ML board from > Einfochips. This board is one of the 96Boards Consumer Edition and AI boards > of the 96Boards family based on i.MXQXP SoC from NXP/Freescale. > > This initial supports contains following peripherals which are tested and > known to work: > > 1. Debug serial via UART2 > 2. SD card > 3. Ethernet > > More information about this board can be found in arrow website: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > arrow.com%2Fen%2Fproducts%2Fimx8-ai-ml%2Farrow-development-tools& > amp;data=02%7C01%7Cpeng.fan%40nxp.com%7C87fef8ef84bf4c6190db08d > 7062ab4f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636984 > 652801075517sdata=gbYa%2Fq8ZXQcId8IUtQIy0dB6axc0H%2FlqBRGY > yamrap0%3Dreserved=0 > > Signed-off-by: Manivannan Sadhasivam > > --- > arch/arm/mach-imx/imx8/Kconfig| 6 + > board/einfochips/imx8qxp_ai_ml/Kconfig| 12 ++ > board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + > board/einfochips/imx8qxp_ai_ml/Makefile | 8 + > board/einfochips/imx8qxp_ai_ml/README | 49 ++ > .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 128 ++ > board/einfochips/imx8qxp_ai_ml/imximage.cfg | 24 +++ > board/einfochips/imx8qxp_ai_ml/spl.c | 59 +++ > configs/imx8qxp_ai_ml_defconfig | 83 + > include/configs/imx8qxp_ai_ml.h | 157 > ++ > 10 files changed, 532 insertions(+) > create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig > create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS > create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile > create mode 100644 board/einfochips/imx8qxp_ai_ml/README > create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c > create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg > create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c > create mode 100644 configs/imx8qxp_ai_ml_defconfig create mode > 100644 include/configs/imx8qxp_ai_ml.h > > diff --git a/arch/arm/mach-imx/imx8/Kconfig > b/arch/arm/mach-imx/imx8/Kconfig index bbe323d5ca..cec21f8dd2 100644 > --- a/arch/arm/mach-imx/imx8/Kconfig > +++ b/arch/arm/mach-imx/imx8/Kconfig > @@ -37,6 +37,11 @@ config TARGET_COLIBRI_IMX8X > select BOARD_LATE_INIT > select IMX8QXP > > +config TARGET_IMX8QXP_AI_ML > + bool "Support i.MX8QXP AI_ML board" > + select BOARD_LATE_INIT > + select IMX8QXP > + > config TARGET_IMX8QM_MEK > bool "Support i.MX8QM MEK board" > select BOARD_LATE_INIT > @@ -49,6 +54,7 @@ config TARGET_IMX8QXP_MEK > > endchoice > > +source "board/einfochips/imx8qxp_ai_ml/Kconfig" > source "board/freescale/imx8qm_mek/Kconfig" > source "board/freescale/imx8qxp_mek/Kconfig" > source "board/toradex/apalis-imx8/Kconfig" > diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig > b/board/einfochips/imx8qxp_ai_ml/Kconfig > new file mode 100644 > index 00..697a831013 > --- /dev/null > +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig > @@ -0,0 +1,12 @@ > +if TARGET_IMX8QXP_AI_ML > + > +config SYS_BOARD > + default "imx8qxp_ai_ml" > + > +config SYS_VENDOR > + default "einfochips" > + > +config SYS_CONFIG_NAME > + default "imx8qxp_ai_ml" > + > +endif > diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > new file mode 100644 > index 00..add0bd9431 > --- /dev/null > +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > @@ -0,0 +1,6 @@ > +i.MX8QXP AI_ML BOARD > +M: Manivannan Sadhasivam > +S: Maintained > +F: board/einfochips/imx8qxp_ai_ml/ > +F: include/configs/imx8qxp_ai_ml.h > +F: configs/imx8qxp_ai_ml_defconfig > diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile > b/board/einfochips/imx8qxp_ai_ml/Makefile > new file mode 100644 > index 00..e08774dc6e > --- /dev/null > +++ b/board/einfochips/imx8qxp_ai_ml/Makefile > @@ -0,0 +1,8 @@ > +# > +# Copyright 2019 Linaro Ltd. > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > + > +obj-y += imx8qxp_ai_ml.o > +obj-$(CONFIG_SPL_BUILD) += spl.o > diff --git a/board/einfochips/imx8qxp_ai_ml/README > b/board/einfochips/imx8qxp_ai_ml/README > new file mode 100644 > index 00..416a157ea8 > --- /dev/null > +++ b/board/einfochips/imx8qxp_ai_ml/README > @@ -0,0 +1,49 @@ > +U-Boot for the Einfochips i.MX8QXP AI_ML board > + > +Quick Start > +=== > + > +- Build the ARM Trusted firmware binary > +- Get scfw_tcm.bin and ahab-container.img > +- Build U-Boot > +- Flash the binary into the SD card > +- Boot > + > +Get and Build the ARM Trusted firmware > +== > + > +$ git clone > +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourc > +e.codeaurora.org%2Fexternal%2Fimx%2Fimx-atfdata=02%7C01%7Cp > eng.fan > +%40nxp.com%7C87fef8ef84bf4c6190db08d7062ab4f8%7C686ea1d3bc2b4c >
Re: [U-Boot] imx7d: CPU core issue in secure mode
> Subject: Re: [U-Boot] imx7d: CPU core issue in secure mode > > + Peng > > Hi Tobias, Peng, > > On Thu, Jul 4, 2019 at 2:20 PM Tobias Junghans > wrote: > > > > Hi, > > > > I'm trying to get an imx7d-based Colibris board running in secure mode > > in order to be able to use the CAAM, especially the HWRNG. However it > > seems like it's currently not possible to boot a mainline kernel > > (4.19) in secure mode with both CPU cores powered up, likely due to > > the missing PSCI firmware in secure mode. When booting in nonsecure > > mode the kernel recognizes both CPU cores while CAAM isn't working. > > Basically it's the same issue as discussed at > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > spinics.net%2Flists%2Fu-boot-v2%2Fmsg33873.htmldata=02%7C01%7 > Cpen > > > g.fan%40nxp.com%7C69f453b8841a47775d7608d705edd3ee%7C686ea1d3b > c2b4c6fa > > > 92cd99c5c301635%7C0%7C0%7C636984391331231662sdata=MtD5x > 15k3vvgBMr > > vqBaZBY9G8AFD0WuE9J8XxIP%2Fz%2Bk%3Dreserved=0 > > > > I'm using the latest mainline U-Boot (2019.07-rc4) with > > CONFIG_ARMV7_BOOT_SEC_DEFAULT=y. Is there anything I can do about > this issue? Try "setenv bootm_boot_mode nonsec" in U-Boot stage. > > > > Thank you and best regards > > > > Tobias > > > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > > s.denx.de%2Flistinfo%2Fu-bootdata=02%7C01%7Cpeng.fan%40nxp.co > m%7C > > > 69f453b8841a47775d7608d705edd3ee%7C686ea1d3bc2b4c6fa92cd99c5c30 > 1635%7C > > > 0%7C0%7C636984391331231662sdata=Ra4mzQpiZpANam1gyhhsy2g > WMHNH3JRNr > > ryP%2BPOiqsM%3Dreserved=0 > > I might be mistaken, but AFAIK there was on-going work done by Peng Fan > regarding proper CAAM initialization in the OP-TEE and further usage in the > mainline kernel. Silvano was doing the CAAM part in OP-TEE. > > As I understood, the initial initialization of the jobrings is done in OP-TEE > (which is booted before U-boot) in secure world, and then linux kernel, > running in normal world, should be able to use it. > Regarding PSCI, frankly, I have no idea who particularly should provide it's > support here: U-boot or OP-TEE (taking into account that in this setup U-boot > is booted in non-secure PL2, so OP-TEE is the only one, who is able to provide > secure runtime services, so-called secure monitor). > > BTW, I also saw some setups, where similar things to do the same in U-boot > (when it's booted in secure mode), which also does have it's own > implementation of secure monitor(subsequently PSCI) and CAAM driver, > which probably does the same type of initialization, as in OP-TEE. > > > Peng, > Could you please provide some comments regarding this? Thanks! There is psci services in U-Boot too. If want non-secure kernel without OP-TEE, Need set "setenv bootm_boot_mode nonsec " in U-Boot stage. If want run OP-TEE, not set the env. Regards, Peng. > > -- > Best regards - Freundliche Grüsse - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opan...@gmail.com > skype: igor.opanyuk > +380 (93) 836 40 67 > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fua.linke > din.com%2Fin%2Fiopaniukdata=02%7C01%7Cpeng.fan%40nxp.com%7 > C69f453b8841a47775d7608d705edd3ee%7C686ea1d3bc2b4c6fa92cd99c5c3 > 01635%7C0%7C0%7C636984391331231662sdata=%2B8TlRt9QP6mV > wMhc3TtHxaZdM%2FvSx09Jz%2BpFhJOlgvg%3Dreserved=0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: edison: Enable SD slot
On Fri, Jul 12, 2019 at 10:42 AM Bin Meng wrote: > > On Wed, Jun 26, 2019 at 4:52 AM Andy Shevchenko > wrote: > > > > Enable SD slot on Intel Edison platform. > > > > By default firmware doesn't put device on active state. Thus, > > we have to do this explicitly. > > > > Signed-off-by: Andy Shevchenko > > --- > > - fix conflict when applying patch > > arch/x86/dts/edison.dts | 5 - > > board/intel/edison/edison.c | 10 ++ > > configs/edison_defconfig| 1 + > > 3 files changed, 11 insertions(+), 5 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: edison: Enable SD slot
On Wed, Jun 26, 2019 at 4:52 AM Andy Shevchenko wrote: > > Enable SD slot on Intel Edison platform. > > By default firmware doesn't put device on active state. Thus, > we have to do this explicitly. > > Signed-off-by: Andy Shevchenko > --- > - fix conflict when applying patch > arch/x86/dts/edison.dts | 5 - > board/intel/edison/edison.c | 10 ++ > configs/edison_defconfig| 1 + > 3 files changed, 11 insertions(+), 5 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] test: pci_ep: add basic pci_ep tests
On Thu, Jul 11, 2019 at 06:04:55PM -0400, Tom Rini wrote: > On Sat, Apr 27, 2019 at 11:15:24AM +0300, Ramon Fried wrote: > > > Add basic PCI endpoint sandbox testing. > > > > Signed-off-by: Ramon Fried > > Reviewed-by: Simon Glass > > Applied to u-boot/master, thanks! This is however now breaking: https://travis-ci.org/u-boot/u-boot/jobs/557569099 -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: add comments to phy APIs
On Thu, Jul 11, 2019 at 11:33 PM Alex Marginean wrote: > > Added a comment on the limitations of phy_find_by_mask API when scanning > MDIO buses with multiple PHYs present. Added short descriptions to the > other APIs in phy.h for consistency. > > Signed-off-by: Alex Marginean > --- > include/phy.h | 80 +++ > 1 file changed, 80 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] test: dm: add a test for MDIO MUX DM uclass
On Thu, Jul 11, 2019 at 3:07 PM Alex Marginean wrote: > > Adds a test using a makeshift MDIO MUX. The test is based on the existing > MDIO test. It uses the last emulated PHY register to verify MUX selection. > > Signed-off-by: Alex Marginean > --- > > Changes in v2: > - no change > Changes in v3: > - no change, just fighting with the email server > Changes in v4: > - a more explicit comment on why relative ordering between mdio-test > and > mdio-mux-test nodes in test.dts matters. > > arch/Kconfig | 1 + > arch/sandbox/dts/test.dts | 23 +++- > drivers/net/Kconfig| 10 > drivers/net/Makefile | 1 + > drivers/net/mdio_mux_sandbox.c | 97 ++ > test/dm/Makefile | 1 + > test/dm/mdio_mux.c | 80 > 7 files changed, 212 insertions(+), 1 deletion(-) > create mode 100644 drivers/net/mdio_mux_sandbox.c > create mode 100644 test/dm/mdio_mux.c > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] doc: bindings: Add description for MDIO MUX dts nodes
On Thu, Jul 11, 2019 at 3:07 PM Alex Marginean
wrote:
>
> Adds a short bindings document describing the expected structure of a MDIO
> MUX dts node. This is based on Linux binding and the example is in fact
> copied from there.
>
> Signed-off-by: Alex Marginean
> ---
>
> Changes in v2:
> - no change
> Changes in v3:
> - no change, just fighting with the email server
> Changes in v4:
> - pulled in full binding example from Linux, added a note on why
> mdio-parent-bus is currently required in U-boot but not in Linux
>
> doc/device-tree-bindings/net/mdio-mux.txt | 138 ++
> 1 file changed, 138 insertions(+)
> create mode 100644 doc/device-tree-bindings/net/mdio-mux.txt
>
> diff --git a/doc/device-tree-bindings/net/mdio-mux.txt
> b/doc/device-tree-bindings/net/mdio-mux.txt
> new file mode 100644
> index 00..63c624a0e5
> --- /dev/null
> +++ b/doc/device-tree-bindings/net/mdio-mux.txt
> @@ -0,0 +1,138 @@
> +The expected structure of an MDIO MUX device tree node is described here.
> This
> +is heavily based on current Linux specification.
> +One notable difference to Linux is that mdio-parent-bus is currently required
> +by u-boot, not optional as is in Linux. Current u-boot MDIO MUX udevice
> class
nits: U-Boot, not u-boot
> +implementation does not have specific support for MDIOs with an integrated
> MUX,
> +the property should be made optional is such support is added.
"if" such support is added
> +
> +The MDIO buses downstream of the MUX should be described in the device tree
> as
> +child nodes as indicated below.
> +
> +Required properties:
> +mdio-parent-bus = a phandle to the MDIO bus used to perform actual I/O.
> This is
> + typically a real MDIO device, unless there are cascaded
> MUXes.
> +#address-cells = <1>, each MDIO group is identified by one 32b value.
> +#size-cells = <0>
> +
> +Other properties:
> +The properties described here are sufficient for MDIO MUX DM class code, but
> +MUX drivers may define additional properties, either required or optional.
> +
> +Required properties in child nodes:
> +reg = value to be configured on the MUX to select the respective downstream
> + MDIO.
> +
> +Child nodes should normally contain PHY nodes, referenced by phandle from
> +ethernet nodes of the eth interfaces using these PHYs.
> +
> +Example structure, extracted from Linux bindings document:
> +
> + /* The parent MDIO bus. */
> + smi1: mdio@118001900 {
> + compatible = "cavium,octeon-3860-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x11800 0x1900 0x0 0x40>;
> + };
> + /*
> + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
> + pair of GPIO lines. Child busses 2 and 3 populated with 4
> + PHYs each.
nits: looks this is coming from the Linux doc, but it's better we fix
the multi-line comment format here.
> +*/
> + mdio-mux {
> + compatible = "mdio-mux-gpio";
> + gpios = < 3 0>, < 4 0>;
> + mdio-parent-bus = <>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + mdio@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy11: ethernet-phy@1 {
> + reg = <1>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy12: ethernet-phy@2 {
> + reg = <2>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy13: ethernet-phy@3 {
> + reg = <3>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> +
Re: [U-Boot] [PATCH 1/1] board: Arcturus: ucp1020: Removing obsoleted stuff
On Thu, Jul 11, 2019 at 11:53 PM Oleksandr Zhadan wrote: > > Removed one of the defconfig(obsoleted) file > and unused CONFIG_MMC_SPI definition to avoid confusion > about if this board using non-DM stuff or not. > uCP1020 is completely DM free board, tested and runs well. > > Signed-off-by: Oleksandr Zhadan > Signed-off-by: Michael Durrant > --- > configs/UCP1020_SPIFLASH_defconfig | 60 > -- > include/configs/UCP1020.h | 1 - > 2 files changed, 61 deletions(-) > delete mode 100644 configs/UCP1020_SPIFLASH_defconfig > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: duplicate IMAGE_SUBSYSTEM_EFI_APPLICATION
Heinrich,
I wonder why we need "asm-generic/pe.h."
If IMAGE_SUBSYSTEM_EFI_APPLICATION can be arch-specific,
why not move other definitions, like * relocation types, too?
-Takahiro Akashi
On Thu, Jul 11, 2019 at 06:28:24PM +0200, Heinrich Schuchardt wrote:
> IMAGE_SUBSYSTEM_EFI_APPLICATION is already defined in
> include/asm-generic/pe.h which is included in include/pe.h. We should
> not define it twice.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/pe.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/pe.h b/include/pe.h
> index 36e1908b7e..c7aeb2dcb6 100644
> --- a/include/pe.h
> +++ b/include/pe.h
> @@ -48,7 +48,6 @@ typedef struct _IMAGE_DOS_HEADER {
>
> #define IMAGE_NT_OPTIONAL_HDR32_MAGIC0x10b
> #define IMAGE_NT_OPTIONAL_HDR64_MAGIC0x20b
> -#define IMAGE_SUBSYSTEM_EFI_APPLICATION 10
>
> typedef struct _IMAGE_FILE_HEADER {
> uint16_t Machine;
> --
> 2.20.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] doc: relocate/rename Android README and add BCB overview
On Thu, May 23, 2019 at 05:32:23PM +0200, Eugeniu Rosca wrote:
> Rename:
> - doc/{README.avb2 => android/avb2.txt}
> - doc/{README.android-fastboot => android/fastboot.txt}
>
> Add a new file documenting the 'bcb' command:
> - doc/android/bcb.txt
>
> The new directory structure has been reviewed by Simon in
> https://patchwork.ozlabs.org/patch/1101107/#2176031 .
>
> Signed-off-by: Eugeniu Rosca
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] cmd: Add 'bcb' command to read/modify/write BCB fields
On Thu, May 23, 2019 at 05:32:22PM +0200, Eugeniu Rosca wrote:
> 'Bootloader Control Block' (BCB) is a well established term/acronym in
> the Android namespace which refers to a location in a dedicated raw
> (i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
> which is used as media for exchanging messages between Android userspace
> (particularly recovery [1]) and an Android-capable bootloader.
>
> On higher level, this allows implementing a subset of Android Bootloader
> Requirements [2], amongst which is the Android-specific bootloader
> flow [3]. Regardless how the latter is implemented in U-Boot ([3] being
> the most memorable example), reading/writing/dumping the BCB fields in
> the development process from inside the U-Boot is a convenient feature.
> Hence, make it available to the users.
>
> Some usage examples of the new command recorded on R-Car H3ULCB-KF
> ('>>>' is an overlay on top of the original console output):
>
> => bcb
> bcb - Load/set/clear/test/dump/store Android BCB fields
>
> Usage:
> bcb load - load BCB from mmc :
> bcb set - set BCB to
> bcb clear [] - clear BCB or all fields
> bcb test - test BCB against
> bcb dump - dump BCB
> bcb store- store BCB back to mmc
>
> Legend:
>- MMC device index containing the BCB partition
> - MMC partition index or name containing the BCB
> - one of {command,status,recovery,stage,reserved}
> - the binary operator used in 'bcb test':
> '=' returns true if matches the string stored in
> '~' returns true if matches a subset of 's string
>- string/text provided as input to bcb {set,test}
> NOTE: any ':' character in will be replaced by line feed
> during 'bcb set' and used as separator by upper layers
>
> => bcb dump command
> Error: Please, load BCB first!
> >>> Users must specify mmc device and partition before any other call
>
> => bcb load 1 misc
> => bcb load 1 1
> >>> The two calls are equivalent (assuming "misc" has index 1)
>
> => bcb dump command
> : 62 6f 6f 74 6f 6e 63 65 2d 73 68 65 6c 6c 00 72bootonce-shell.r
> 0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
> >>> The output is in binary/string format for convenience
> >>> The output size matches the size of inspected BCB field
> >>> (32 bytes in case of 'command')
>
> => bcb test command = bootonce-shell && echo true
> true
> => bcb test command = bootonce-shell- && echo true
> => bcb test command = bootonce-shel && echo true
> >>> The '=' operator returns 'true' on perfect match
>
> => bcb test command ~ bootonce-shel && echo true
> true
> => bcb test command ~ bootonce-shell && echo true
> true
> >>> The '~' operator returns 'true' on substring match
>
> => bcb set command recovery
> => bcb dump command
> : 72 65 63 6f 76 65 72 79 00 73 68 65 6c 6c 00 72recovery.shell.r
> 0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
> >>> The new value is NULL-terminated and stored in the BCB field
>
> => bcb set recovery "msg1:msg2:msg3"
> => bcb dump recovery
> 0040: 6d 73 67 31 0a 6d 73 67 32 0a 6d 73 67 33 00 00msg1.msg2.msg3..
> 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>> --- snip ---
> >>> Every ':' is replaced by line-feed '\n' (0xA). The latter is used
> >>> as separator between individual commands by Android userspace
>
> => bcb store
> >>> Flush/store the BCB structure to MMC
>
> [1] https://android.googlesource.com/platform/bootable/recovery
> [2] https://source.android.com/devices/bootloader
> [3] https://patchwork.ozlabs.org/patch/746835/
> ("[U-Boot,5/6] Initial support for the Android Bootloader flow")
>
> Signed-off-by: Eugeniu Rosca
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mach-omap2: am33xx: Init pinmux before clock
On Sat, May 25, 2019 at 10:40:35PM +0200, Marek Vasut wrote: > The board_early_init_f() inits clock before initing pinmux. However, > the clock configuration code might need to adjust PMIC settings of a > PMIC on I2C bus (e.g. board/ti/am335x/board.c does that). If the I2C > bus pin muxing is not configured before attempting to communicate > with the PMIC, the communication will silently fail and the prcm_init() > may configure fast enough CPU clock that the default voltage provided > by the PMIC would be insufficient and the platform would become > unstable. > > Signed-off-by: Marek Vasut > Cc: Jean-Jacques Hiblot > Cc: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: pca953x: Add TI TCA9539 compatible string
On Sat, May 25, 2019 at 10:52:20PM +0200, Marek Vasut wrote: > Add TI TCA9539 compatible string for yet another I2C GPIO expander. > > Signed-off-by: Marek Vasut > Cc: Mario Six > Cc: Peng Fan > Cc: Simon Glass > Reviewed-by: Peng Fan Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] arm: spear: Return to BootROM if failing to boot from the main device
On Tue, May 07, 2019 at 02:18:54PM +0200, Miquel Raynal wrote: > Overload the weak function board_boot_order() so that besides choosing > the main boot device, we can fallback on USB boot by returning in the > BootROM, eg. if the NOR flash is empty while it was the primary boot > medium. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/12] arm: spear: Drop false comment
On Tue, May 07, 2019 at 02:18:46PM +0200, Miquel Raynal wrote: > SPL BSS lies in SRAM and is actually initialized to 0 by the SPL in > arch/arm/lib/crt0.S:_main(), which is called by cpu_init_crit. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/12] arm: spear: Do not link the _main branch
On Tue, May 07, 2019 at 02:18:53PM +0200, Miquel Raynal wrote: > The _main call is not supposed to return at all: don't link the > branch. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 1/2] configs: Rename CONFIG_IMAGE_FORMAT_LEGACY to CONFIG_LEGACY_IMAGE_FORMAT
On Thu, May 23, 2019 at 07:14:07AM -0400, Tom Rini wrote: > The name CONFIG_LEGACY_IMAGE_FORMAT reads slightly better along with > allowing us to avoid a rather nasty Kbuild/Kconfig issue down the line > with CONFIG_IS_ENABLED(IMAGE_FORMAT_LEGACY). In a few places outside of > cmd/ switch to using CONFIG_IS_ENABLED() to test what is set. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] arm: spear: Reference the link register with LR instead of R14
On Tue, May 07, 2019 at 02:18:50PM +0200, Miquel Raynal wrote: > The link register is stored in R14. ARM assembly code allows to use > the 'lr' name to reference it instead of 'r14' which is not very > meaningful. Do the substitution to ease the reading. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 2/2] SPL: Default to disabling legacy image support when using FIT
On Thu, May 23, 2019 at 07:14:08AM -0400, Tom Rini wrote: > When we have a FIT image being used by SPL by default that means the > most common case is that we'll never run into a legacy image. Disable > legacy image support by default in that case to reclaim space. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] include: android_bootloader_message.h: Minimize the diff to AOSP
On Thu, May 23, 2019 at 05:32:21PM +0200, Eugeniu Rosca wrote: > Perform the following updates: > - Relocate the commit id from the file to the description of U-Boot >commit. The AOSP commit is c784ce50e8c10eaf70e1f97e24e8324aef45faf5. >This is done to avoid stale references in the file itself. The >reasoning is in https://patchwork.ozlabs.org/patch/1098056/#2170209. > - Minimize the diff to AOSP, to decrease the effort of the next AOSP >backports. The background can be found in: >https://patchwork.ozlabs.org/patch/1080394/#2168454. > - Guard the static_assert() calls by #ifndef __UBOOT__ ... #endif, >to avoid compilation failures of files including the header. > > Signed-off-by: Eugeniu Rosca > Reviewed-by: Sam Protsenko > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/12] spl: Fix typo in kernel doc
On Tue, May 07, 2019 at 02:18:43PM +0200, Miquel Raynal wrote: > Fix a tiny typo in boot_from_devices() kernel doc. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tpm: wait for valid status
On Thu, May 16, 2019 at 06:32:48PM +0200, Roman Kapl wrote: > The TPM specification says that the EXPECT_DATA bit is not valid until > the VALID bit is set. Wait for that bit to be set. Fixes problems with > Ifineon SPI TPM. > > Signed-off-by: Roman Kapl Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/12] arm: spear: Support returning to BootROM
On Tue, May 07, 2019 at 02:18:52PM +0200, Miquel Raynal wrote: > Implement the weak board_return_to_bootrom() function so that when > enabling the spl_bootrom.c driver, one can make use of usbboot on > spear platforms. All necessary information to return to the BootROM > are stored in the BootROM's stack. The SPL stack pointer is reset so > we save the BootROM's stack pointer into the SPL .data section. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/12] arm: spear: Simplify start.S organization
On Tue, May 07, 2019 at 02:18:51PM +0200, Miquel Raynal wrote: > There is no reason to do the few spear-related initialization, in a > different procedure than 'reset'. Spare one branching and get a linear > code flow by removing this indirection. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] arm: spear: Fix the main comment in start.S
On Tue, May 07, 2019 at 02:18:47PM +0200, Miquel Raynal wrote: > This comment describes the board state at the moment where we enter > the SPL. The description is entirely wrong; re-write it to fit the > reality. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/12] arm: spear: Purely cosmetic changes in start.S
On Tue, May 07, 2019 at 02:18:48PM +0200, Miquel Raynal wrote: > Before cleaning a bit further the spear/start.S file, apply a few > cosmetic changes: capital letters, comment indentation and small > rewriting. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12] arm: spear: Use PUSH/POP mnemonics when relevant
On Tue, May 07, 2019 at 02:18:49PM +0200, Miquel Raynal wrote: > Quoting ARM "RealView Compilation Tools Assembler Guide v4.0": > > PUSH and POP are synonyms for STMDB and LDM (or LDMIA), with > the base register sp (r13), and the adjusted address written > back to the base register. > PUSH and POP are the preferred mnemonic in these cases. > > Let's follow this recommandation to ease the reading and substitute > LDMIA/STMDB operations with PUSH/POP mnemonics. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] arm: spear: Call the SPL 'SPL', not 'Xloader'
On Tue, May 07, 2019 at 02:18:45PM +0200, Miquel Raynal wrote: > Rename Xloader as SPL in comments. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] pci_ep: add pci endpoint sandbox driver
On Sat, Apr 27, 2019 at 11:15:23AM +0300, Ramon Fried wrote: > Add a dummy PCI endpoint for sandbox. > Supporting only a single function, it allows setting > and reading header configuration. > > Signed-off-by: Ramon Fried > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/12] arm: spear: Drop useless board_init_r call
On Tue, May 07, 2019 at 02:18:44PM +0200, Miquel Raynal wrote: > It is clearly stated that board_init_f should *not* call > board_init_r. Indeed, board_init_f should return. The code will > continue through arch/arm/lib/crt0.S which will do more setup before > calling board_init_r. > > Signed-off-by: Miquel Raynal > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] pci_ep: add Cadence PCIe endpoint driver
On Sat, Apr 27, 2019 at 11:15:22AM +0300, Ramon Fried wrote: > Add Cadence PCIe endpoint driver supporting configuration > of header, bars and MSI for device. > > Signed-off-by: Ramon Fried > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] test: pci_ep: add basic pci_ep tests
On Sat, Apr 27, 2019 at 11:15:24AM +0300, Ramon Fried wrote: > Add basic PCI endpoint sandbox testing. > > Signed-off-by: Ramon Fried > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] drivers: pci_ep: Introduce UCLASS_PCI_EP uclass
On Sat, Apr 27, 2019 at 11:15:21AM +0300, Ramon Fried wrote: > Introduce new UCLASS_PCI_EP class for handling PCI endpoint > devices, allowing to set various attributes of the PCI endpoint > device, such as: > * configuration space header > * BAR definitions > * outband memory mapping > * start/stop PCI link > > Signed-off-by: Ramon Fried > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: ti: boot: Handle reboot reason from BCB
Hi Sam,
On Tue, Jul 09, 2019 at 05:45:43PM +0300, Sam Protsenko wrote:
> "emmc_android_boot=" \
> + "if bcb load " __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) " misc; " \
> + "then " \
> + "if bcb test command = bootonce-bootloader; then " \
> + "echo BCB: Bootloader boot...; " \
> + "bcb clear command; bcb store; " \
Assuming there are multiple reboot reasons of type "bootonce/oneshot"
(i.e. assumed to be cleared once detected/handled), 'bcb test' could
implement the '-c' (clear) flag. This would allow removing the
"bcb clear command; bcb store;" line, w/o altering the behavior.
It could be done in phase 2 (optimization/refinement).
> + FASTBOOT_CMD \
> + "elif bcb test command = boot-recovery; then " \
> + "echo BCB: Recovery boot...; " \
> + "echo Warning: recovery boot is not implemented; " \
> + "echo Performing normal boot for now...; " \
> + "run emmc_android_normal_boot; " \
> + "else " \
> + "echo BCB: Normal boot requested...; " \
> + "run emmc_android_normal_boot; " \
> + "fi; " \
> + "else " \
> + "echo Warning: BCB is corrupted or does not exist; " \
> + "echo Performing normal boot...; " \
> + "run emmc_android_normal_boot; " \
> + "fi;\0" \
As a general comment, yes, arguments can be brought that this scripted
handling is getting hairy and could be replaced by a command like
boot{a,_android} (you name it).
In my opinion, the main downside of "boot{a,_android}" wrapper is that
it implies sprinkling U-Boot with special-purpose variables like
${fastbootcmd} [1], ${recoverycmd}, ${my_usecase_cmd}, etc (the number
of those would likely match the number of if/else branches in this
patch). Decentralized usage of those variables (i.e. set at point A and
read/used at point B) would IMHO:
- complicate the boot flow and its understanding, hence would
- require to write and maintain additional documentation
- open doors for creative issues
I contrast to the above, the approach taken in this patch:
- avoids any special-purpose global variables
- avoids spawning yet another boot{*} command
- centralizes/limits the boot flow handling to one file
- doesn't require much documentation (the code is self-explanatory)
- in case of bugs, would require coming back to the same place
- makes debugging easier
> + "emmc_android_normal_boot=" \
> "echo Trying to boot Android from eMMC ...; " \
> "run update_to_fit; " \
> "setenv eval_bootargs setenv bootargs $bootargs; " \
> @@ -176,8 +201,7 @@
> "if test ${dofastboot} -eq 1; then " \
> "echo Boot fastboot requested, resetting dofastboot ...;" \
> "setenv dofastboot 0; saveenv;" \
> - "echo Booting into fastboot ...; " \
> - "fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
> + FASTBOOT_CMD \
> "fi;" \
> "if test ${boot_fit} -eq 1; then " \
> "run update_to_fit;"\
That said, I still admit that my statements could be highly subjective
and that the best of our collective experience (as users, developers and
maintainers) would be achieved in a different way than described.
Below is based on code review only (can't test due to lack of HW):
Reviewed-by: Eugeniu Rosca
[1]
https://android.googlesource.com/platform/external/u-boot/+/7d8d87584d7c/cmd/boot_android.c#67
--
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] net: introduce packet capture support
On Sat, Jun 22, 2019 at 1:50 PM Ramon Fried wrote: > > Add support for capturing ethernet packets and storing > them in memory in PCAP(2.4) format, later to be analyzed by > any PCAP viewer software (IE. Wireshark) > > This feature greatly assist debugging network issues such > as detecting dropped packets, packet corruption etc. > > Signed-off-by: Ramon Fried > Reviewed-by: Alex Marginean > Tested-by: Alex Marginean This is a nice feature to have. We need a unit test for it, though. Please add it to a sandbox test and exercise it, then have the test try to load the resulting file with tshark to ensure a valid format. There are potentially other things in the header that is printed that can be used for further validation. Thanks for this feature. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] doc: pcap: add pcap cmd documentation
On Sat, Jun 22, 2019 at 1:53 PM Ramon Fried wrote: > > Add documentation for new "pcap" command. > > Signed-off-by: Ramon Fried > --- > v2: remove duplicated lines from example > doc/README.pcap | 61 + > 1 file changed, 61 insertions(+) > create mode 100644 doc/README.pcap > > diff --git a/doc/README.pcap b/doc/README.pcap > new file mode 100644 > index 00..25c85ae271 > --- /dev/null > +++ b/doc/README.pcap > @@ -0,0 +1,61 @@ > +PCAP: > + > +U-boot supports live ethernet packet capture in PCAP(2.4) format. > +This is enabled by CONFIG_CMD_PCAP. > + > +The capture is stored on physical memory, and should be copied to > +a machine capabale of parsing and displaying PCAP files (IE. wireshark) > +If networking works properly one can copy the capture file from physical > memory > +using tftpput, or save it to local storage with (sf write, mmc write, > fatwrite, etc) > + > +the pcap capturing requires maximum buffer size. > +when the buffer is full, packets will silently drop. > +check the status using "pcap status" to see if the buffer is full, > +if so, consider increasing the buffer size. Based on the change I asked for in the other patch, please reword this to match the behavior. > + > +Usage example: > + > +# pcap init 0x10 10 > +PCAP capture initialized: addr: 0x8010 max length: 10 > + > +# pcap start > +# env set ipaddr 10.0.2.15; env set serverip 10.0.2.2; tftp uImage64 > +eth0@1000: PHY present at 0 > +eth0@1000: link up, 1000Mbps full-duplex (lpa: 0x7c00) > +Using eth0@1000 device > +TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > +Filename 'uImage64'. > +Load address: 0x8800 > +Loading: # > + # > + # > + # > + # > + # > + # > + # > + # > + # > + 18.2 MiB/s > +done > +Bytes transferred = 8359376 (7f8dd0 hex) > +PCAP status: > +Initialized addr: 0x8010max length: 10 > +Status: Active. file size: 1 > +Incoming packets: 66 Outgoing packets: 67 > +!!! Buffer is full, consider increasing buffer size !!! > + > + > +# pcap stop > +# tftpput 0x8010 10 10.0.2.2:capture.pcap > + > -- > 2.22.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] net: introduce packet capture support
On Sat, Jun 22, 2019 at 1:50 PM Ramon Fried wrote:
>
> Add support for capturing ethernet packets and storing
> them in memory in PCAP(2.4) format, later to be analyzed by
> any PCAP viewer software (IE. Wireshark)
>
> This feature greatly assist debugging network issues such
> as detecting dropped packets, packet corruption etc.
>
> Signed-off-by: Ramon Fried
> Reviewed-by: Alex Marginean
> Tested-by: Alex Marginean
> ---
> v2: Fix type assignmnet to header.ts_sec
> v3: Several suggestion changes by Bin and Alex:
>* Change to implementation to command based.
>* Added counters for incoming/outgoing packets.
>* Support clearing the capture for multiple captures.
>* Added documentation (separate patch).
>
> cmd/Kconfig | 7 +++
> cmd/net.c | 63 +
> include/net.h | 56 +++
> net/Makefile | 1 +
> net/net.c | 8 +++
> net/pcap.c| 152 ++
> 6 files changed, 287 insertions(+)
> create mode 100644 net/pcap.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 0badcb3fe0..638f979f28 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1239,6 +1239,13 @@ config BOOTP_NTPSERVER
> bool "Request & store 'ntpserverip' from BOOTP/DHCP server"
> depends on CMD_BOOTP
>
> +config CMD_PCAP
> + bool "pcap capture"
> + help
> + Selecting this will allow capturing all Ethernet packets and store
> + them in physical memory in a PCAP formated file,
> + later to be analyzed by PCAP reader application (IE. WireShark).
> +
> config BOOTP_PXE
> bool "Send PXE client arch to BOOTP/DHCP server"
> default y
> diff --git a/cmd/net.c b/cmd/net.c
> index 89721b8f8b..5022f1dbcc 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -457,3 +457,66 @@ U_BOOT_CMD(
> );
>
> #endif /* CONFIG_CMD_LINK_LOCAL */
> +
> +#if defined(CONFIG_CMD_PCAP)
Please just move this to a separate cmd/pcap.c instead of this ifdef.
> +static int do_pcap_init(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + phys_addr_t addr;
> + unsigned int size;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + addr = simple_strtoul(argv[1], NULL, 16);
> + size = simple_strtoul(argv[2], NULL, 10);
> +
> + return pcap_init(addr, size) ? CMD_RET_FAILURE : CMD_RET_SUCCESS;
> +}
> +
> +static int do_pcap_start(cmd_tbl_t *cmdtp, int flag, int argc,
> +char * const argv[])
> +{
> + return pcap_start_stop(true) ? CMD_RET_FAILURE : CMD_RET_SUCCESS;
> +}
> +
> +static int do_pcap_stop(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + return pcap_start_stop(false) ? CMD_RET_FAILURE : CMD_RET_SUCCESS;
> +}
> +
> +static int do_pcap_status(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + return pcap_print_status() ? CMD_RET_FAILURE : CMD_RET_SUCCESS;
> +}
> +
> +static int do_pcap_clear(cmd_tbl_t *cmdtp, int flag, int argc,
> +char * const argv[])
> +{
> + return pcap_clear() ? CMD_RET_FAILURE : CMD_RET_SUCCESS;
> +}
> +
> +static char pcap_help_text[] =
> + "- network packet capture\n\n"
> + "pcap\n"
> + "pcap init\t\t\t \n"
> + "pcap start\t\t\tstart capture\n"
> + "pcap stop\t\t\tstop capture\n"
> + "pcap status\t\t\tprint status\n"
> + "pcap clear\t\t\tclear capture buffer\n"
> + "\n"
> + "With:\n"
> + "\t: user address to which pcap will be stored (hexedcimal)\n"
> + "\t: Maximum size of pcap file (decimal)\n"
> + "\n";
> +
> +U_BOOT_CMD_WITH_SUBCMDS(pcap, "pcap", pcap_help_text,
> + U_BOOT_SUBCMD_MKENT(init, 3, 0, do_pcap_init),
> + U_BOOT_SUBCMD_MKENT(start, 1, 0, do_pcap_start),
> + U_BOOT_SUBCMD_MKENT(stop, 1, 0, do_pcap_stop),
> + U_BOOT_SUBCMD_MKENT(status, 1, 0, do_pcap_status),
> + U_BOOT_SUBCMD_MKENT(clear, 1, 0, do_pcap_clear),
> +);
> +#endif /* CONFIG_CMD_PCAP */
> diff --git a/include/net.h b/include/net.h
> index 44b32385c4..f0289c3cde 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -630,6 +630,58 @@ bool arp_is_waiting(void); /* Waiting for ARP
> reply? */
> void net_set_icmp_handler(rxhand_icmp_f *f); /* Set ICMP RX handler */
> void net_set_timeout_handler(ulong, thand_f *);/* Set timeout handler */
>
> +/* PCAP extension */
Please put this stuff in include/net/pcap.h
> +
> +/**
> + * pcap_init() - Initialize PCAP memory buffer
> + *
> + * @paddr physicaly memory address to store buffer
> + * @size maximum size of capture file in memory
> + *
> + * @return 0 on success, -ERROR on error
> + */
> +int pcap_init(phys_addr_t paddr, unsigned long size);
> +
> +/**
> + * pcap_start_stop() - start / stop pcap
Re: [U-Boot] [PATCH v4 1/2] fit: Support compression for non-kernel components (e.g. FDT)
Hi Tom, > This breaks tools-only_defconfig in non-trivial ways due to calling > bootm_decomp_image() which is not normally available to it. Can you > please update things (it may just end up being common/Makefile that > needs tweaking) so that tools-only builds? I'll then take a look and > make sure we don't also see unexpected size growth elsewhere. Thanks! Thanks for pointing that out! I think the best solution here would be to move bootm_decomp_image() out of bootm.c, if we now want to have it available in configurations that don't compile that file. I think image.c would be a better home for it. Added another patch to move the function and sent out v5 of the series, let me know what you think! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 3/3] fit: Support compat string property in configuration node
This patch adds support for an optional optimization to compatible
string matching where the compatible string property from the root node
of the kernel FDT can be copied into the configuration node of the FIT
image. This is most useful when using compressed FDTs or when using FDT
overlays, where the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
---
- No changes for v2
- No changes for v3
- Changes for v4:
- Added documentation for compatible string in config node.
- Added example .its file for compressed FDT with compat string in
config node.
- No changes for v5
common/image-fit.c| 67 -
doc/uImage.FIT/kernel_fdts_compressed.its | 73 +++
doc/uImage.FIT/source_file_format.txt | 7 +++
3 files changed, 119 insertions(+), 28 deletions(-)
create mode 100644 doc/uImage.FIT/kernel_fdts_compressed.its
diff --git a/common/image-fit.c b/common/image-fit.c
index c9ffc441aa..e346fed550 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1522,6 +1522,10 @@ int fit_check_format(const void *fit)
* compatible list, "foo,bar", matches a compatible string in the root of fdt1.
* "bim,bam" in fdt2 matches the second string which isn't as good as fdt1.
*
+ * As an optimization, the compatible property from the FDT's root node can be
+ * copied into the configuration node in the FIT image. This is required to
+ * match configurations with compressed FDTs.
+ *
* returns:
* offset to the configuration to use if one was found
* -1 otherwise
@@ -1554,55 +1558,62 @@ int fit_conf_find_compat(const void *fit, const void
*fdt)
for (noffset = fdt_next_node(fit, confs_noffset, );
(noffset >= 0) && (ndepth > 0);
noffset = fdt_next_node(fit, noffset, )) {
- const void *kfdt;
+ const void *fdt;
const char *kfdt_name;
- int kfdt_noffset;
+ int kfdt_noffset, compat_noffset;
const char *cur_fdt_compat;
int len;
- size_t size;
+ size_t sz;
int i;
if (ndepth > 1)
continue;
- kfdt_name = fdt_getprop(fit, noffset, "fdt", );
- if (!kfdt_name) {
- debug("No fdt property found.\n");
- continue;
- }
- kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
- kfdt_name);
- if (kfdt_noffset < 0) {
- debug("No image node named \"%s\" found.\n",
- kfdt_name);
- continue;
- }
+ /* If there's a compat property in the config node, use that. */
+ if (fdt_getprop(fit, noffset, "compatible", NULL)) {
+ fdt = fit;/* search in FIT image */
+ compat_noffset = noffset; /* search under config node */
+ } else {/* Otherwise extract it from the kernel FDT. */
+ kfdt_name = fdt_getprop(fit, noffset, "fdt", );
+ if (!kfdt_name) {
+ debug("No fdt property found.\n");
+ continue;
+ }
+ kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
+ kfdt_name);
+ if (kfdt_noffset < 0) {
+ debug("No image node named \"%s\" found.\n",
+ kfdt_name);
+ continue;
+ }
- if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
- debug("Can't extract compat from \"%s\" (compressed)\n",
- kfdt_name);
- continue;
- }
+ if (!fit_image_check_comp(fit, kfdt_noffset,
+ IH_COMP_NONE)) {
+ debug("Can't extract compat from \"%s\" "
+ "(compressed)\n", kfdt_name);
+ continue;
+ }
- /*
-* Get a pointer to this configuration's fdt.
-*/
- if (fit_image_get_data(fit, kfdt_noffset, , )) {
- debug("Failed to get fdt \"%s\".\n", kfdt_name);
- continue;
+ /* search in this config's kernel FDT */
+ if (fit_image_get_data(fit, kfdt_noffset, , )) {
+ debug("Failed to get fdt \"%s\".\n", kfdt_name);
+
[U-Boot] [PATCH v5 2/3] fit: Support compression for non-kernel components (e.g. FDT)
This patch adds support for compressing non-kernel image nodes in a FIT
image (kernel nodes could already be compressed previously). This can
reduce the size of FIT images and therefore improve boot times
(especially when an image bundles many different kernel FDTs). The
images will automatically be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
---
- Changes for v2:
- Changed from only supporting compressed FDTs to supporting all
non-kernel image node types.
- Changes for v3:
- Fixed up some debug output that was still written for v1.
- Fixed a mistake with handling FIT_LOAD_OPTIONAL_NON_ZERO when
'load' was 0 (i.e. unset).
- Added compression test case to the test_fit pytest.
- No changes for v4
- No changes for v5
common/image-fit.c| 86 +++
test/py/tests/test_fit.py | 29 +++--
2 files changed, 77 insertions(+), 38 deletions(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index a74b44f298..c9ffc441aa 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -22,6 +22,7 @@
DECLARE_GLOBAL_DATA_PTR;
#endif /* !USE_HOSTCC*/
+#include
#include
#include
#include
@@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void
*fdt)
kfdt_name);
continue;
}
+
+ if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
+ debug("Can't extract compat from \"%s\" (compressed)\n",
+ kfdt_name);
+ continue;
+ }
+
/*
* Get a pointer to this configuration's fdt.
*/
@@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
const char *fit_uname_config;
const char *fit_base_uname_config;
const void *fit;
- const void *buf;
+ void *buf;
+ void *loadbuf;
size_t size;
int type_ok, os_ok;
- ulong load, data, len;
- uint8_t os;
+ ulong load, load_end, data, len;
+ uint8_t os, comp;
#ifndef USE_HOSTCC
uint8_t os_arch;
#endif
@@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
images->os.arch = os_arch;
#endif
- if (image_type == IH_TYPE_FLATDT &&
- !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
- puts("FDT image is compressed");
- return -EPROTONOSUPPORT;
- }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
type_ok = fit_image_check_type(fit, noffset, image_type) ||
fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
@@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
/* get image data address and length */
- if (fit_image_get_data_and_size(fit, noffset, , )) {
+ if (fit_image_get_data_and_size(fit, noffset,
+ (const void **), )) {
printf("Could not find %s subimage data!\n", prop_name);
bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
return -ENOENT;
@@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
#if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
/* perform any post-processing on the image data */
- board_fit_image_post_process((void **), );
+ board_fit_image_post_process(, );
#endif
len = (ulong)size;
- /* verify that image data is a proper FDT blob */
- if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
- puts("Subimage data is not a FDT");
- return -ENOEXEC;
- }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
- /*
-* Work-around for eldk-4.2 which gives this warning if we try to
-* cast in the unmap_sysmem() call:
-* warning: initialization discards qualifiers from pointer target type
-*/
- {
- void *vbuf = (void *)buf;
-
- data = map_to_sysmem(vbuf);
- }
-
+ data = map_to_sysmem(buf);
+ load = data;
if (load_op == FIT_LOAD_IGNORED) {
/* Don't load */
} else if (fit_image_get_load(fit, noffset, )) {
@@ -1974,8 +1963,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
} else if (load_op != FIT_LOAD_OPTIONAL_NON_ZERO || load) {
ulong image_start, image_end;
- ulong load_end;
- void *dst;
/*
* move
[U-Boot] [PATCH v5 1/3] common: Move bootm_decomp_image() to image.c (as image_decomp())
Upcoming patches want to add decompression to use cases that are no
longer directly related to booting. It makes sense to retain a single
decompression routine, but it should no longer be in bootm.c (which is
not compiled for all configurations). This patch moves
bootm_decomp_image() to image.c and renames it to image_decomp() in
preparation of those upcoming patches.
Signed-off-by: Julius Werner
---
- First version: v5
common/bootm.c | 148 ++---
common/image.c | 111 ++
include/bootm.h| 17 --
include/image.h| 17 ++
test/compression.c | 24
5 files changed, 160 insertions(+), 157 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index d193751647..2e64140df6 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -7,17 +7,12 @@
#ifndef USE_HOSTCC
#include
#include
-#include
#include
#include
#include
#include
#include
#include
-#include
-#include
-#include
-#include
#if defined(CONFIG_CMD_USB)
#include
#endif
@@ -299,23 +294,6 @@ static int bootm_find_other(cmd_tbl_t *cmdtp, int flag,
int argc,
}
#endif /* USE_HOSTC */
-/**
- * print_decomp_msg() - Print a suitable decompression/loading message
- *
- * @type: OS type (IH_OS_...)
- * @comp_type: Compression type being used (IH_COMP_...)
- * @is_xip:true if the load address matches the image start
- */
-static void print_decomp_msg(int comp_type, int type, bool is_xip)
-{
- const char *name = genimg_get_type_name(type);
-
- if (comp_type == IH_COMP_NONE)
- printf(" %s %s ... ", is_xip ? "XIP" : "Loading", name);
- else
- printf(" Uncompressing %s ... ", name);
-}
-
/**
* handle_decomp_error() - display a decompression error
*
@@ -325,16 +303,18 @@ static void print_decomp_msg(int comp_type, int type,
bool is_xip)
*
* @comp_type: Compression type being used (IH_COMP_...)
* @uncomp_size: Number of bytes uncompressed
- * @unc_len: Amount of space available for decompression
- * @ret: Error code to report
- * @return BOOTM_ERR_RESET, indicating that the board must be reset
+ * @ret: errno error code received from compression library
+ * @return Appropriate BOOTM_ERR_ error code
*/
-static int handle_decomp_error(int comp_type, size_t uncomp_size,
- size_t unc_len, int ret)
+static int handle_decomp_error(int comp_type, size_t uncomp_size, int ret)
{
const char *name = genimg_get_comp_name(comp_type);
- if (uncomp_size >= unc_len)
+ /* ENOSYS means unimplemented compression type, don't reset. */
+ if (ret == -ENOSYS)
+ return BOOTM_ERR_UNIMPLEMENTED;
+
+ if (uncomp_size >= CONFIG_SYS_BOOTM_LEN)
printf("Image too large: increase CONFIG_SYS_BOOTM_LEN\n");
else
printf("%s: uncompress error %d\n", name, ret);
@@ -352,93 +332,6 @@ static int handle_decomp_error(int comp_type, size_t
uncomp_size,
return BOOTM_ERR_RESET;
}
-int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
- void *load_buf, void *image_buf, ulong image_len,
- uint unc_len, ulong *load_end)
-{
- int ret = 0;
-
- *load_end = load;
- print_decomp_msg(comp, type, load == image_start);
-
- /*
-* Load the image to the right place, decompressing if needed. After
-* this, image_len will be set to the number of uncompressed bytes
-* loaded, ret will be non-zero on error.
-*/
- switch (comp) {
- case IH_COMP_NONE:
- if (load == image_start)
- break;
- if (image_len <= unc_len)
- memmove_wd(load_buf, image_buf, image_len, CHUNKSZ);
- else
- ret = 1;
- break;
-#ifdef CONFIG_GZIP
- case IH_COMP_GZIP: {
- ret = gunzip(load_buf, unc_len, image_buf, _len);
- break;
- }
-#endif /* CONFIG_GZIP */
-#ifdef CONFIG_BZIP2
- case IH_COMP_BZIP2: {
- uint size = unc_len;
-
- /*
-* If we've got less than 4 MB of malloc() space,
-* use slower decompression algorithm which requires
-* at most 2300 KB of memory.
-*/
- ret = BZ2_bzBuffToBuffDecompress(load_buf, ,
- image_buf, image_len,
- CONFIG_SYS_MALLOC_LEN < (4096 * 1024), 0);
- image_len = size;
- break;
- }
-#endif /* CONFIG_BZIP2 */
-#ifdef CONFIG_LZMA
- case IH_COMP_LZMA: {
- SizeT lzma_len = unc_len;
-
- ret = lzmaBuffToBuffDecompress(load_buf, _len,
- image_buf, image_len);
- image_len = lzma_len;
-
[U-Boot] [PATCH v5 0/3] fit: Image node compression
This patch series adds compression support for non-kernel FIT image nodes (e.g. FDTs). The first patch is a preparatory refactoring, the second adds the compression support itself, and the third adds a new feature to compatible string matching that allows it to be useful with compressed FDTs. Sandbox-tested with FIT images with and without compressed FDTs, with and without overlays, in both compatible string matching and direct config selection modes. Also expanded the test_fit pytest to include a case with compressed kernel, FDT and ramdisk. Julius Werner (3): common: Move bootm_decomp_image() to image.c (as image_decomp()) - First version: v5 fit: Support compression for non-kernel components (e.g. FDT) - Changes for v2: - Changed from only supporting compressed FDTs to supporting all non-kernel image node types. - Changes for v3: - Fixed up some debug output that was still written for v1. - Fixed a mistake with handling FIT_LOAD_OPTIONAL_NON_ZERO when 'load' was 0 (i.e. unset). - Added compression test case to the test_fit pytest. - No changes for v4 - No changes for v5 fit: Support compat string property in configuration node - No changes for v2 - No changes for v3 - Changes for v4: - Added documentation for compatible string in config node. - Added example .its file for compressed FDT with compat string in config node. - No changes for v5 common/bootm.c| 148 +++--- common/image-fit.c| 143 - common/image.c| 111 doc/uImage.FIT/kernel_fdts_compressed.its | 73 +++ doc/uImage.FIT/source_file_format.txt | 7 + include/bootm.h | 17 --- include/image.h | 17 +++ test/compression.c| 24 ++-- test/py/tests/test_fit.py | 29 - 9 files changed, 351 insertions(+), 218 deletions(-) create mode 100644 doc/uImage.FIT/kernel_fdts_compressed.its -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: socfpga: gen5: don't zero bss in board_init_f()
The socfpga gen5 SPL manually zeroed bss in board_init_f(). Now that the DDR driver does not use bss any more, bss is not used before board_init_r() and we can remove this hack. Signed-off-by: Simon Goldschmidt --- arch/arm/mach-socfpga/spl_gen5.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c index 87b76b47de..47e63709ad 100644 --- a/arch/arm/mach-socfpga/spl_gen5.c +++ b/arch/arm/mach-socfpga/spl_gen5.c @@ -79,8 +79,6 @@ void board_init_f(ulong dummy) writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN, _regs->eccgrp_ocram); - memset(__bss_start, 0, __bss_end - __bss_start); - socfpga_sdram_remap_zero(); socfpga_pl310_clear(); -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] arm: socfpga: gen5 SPL bss cleanup
This series removes the invalid usage of bss before board_init_r in SPL. Simon Goldschmidt (2): dm: ddr: socfpga: fix gen5 ddr driver to not use bss arm: socfpga: gen5: don't zero bss in board_init_f() arch/arm/mach-socfpga/spl_gen5.c |2 - drivers/ddr/altera/sequencer.c | 1346 -- drivers/ddr/altera/sequencer.h | 36 +- 3 files changed, 740 insertions(+), 644 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL
Hi Tom, On Thu, Jul 11, 2019 at 02:43:17PM -0400, Tom Rini wrote: > On Thu, Jul 11, 2019 at 01:12:16PM -0500, Andreas Dannenberg wrote: > > Also some additional background why I am even looking into this. One of > > our platforms (AM335x) has a regression building on Travis CI with some > > of our pending patches applied. Interestingly, this only happens on > > Travis, which still uses GCC 7.3.0 for arm (why?). With newer, more > > efficient compilers there is no such issue. > > On this last point, gcc 7.3 is the current GCC release that doesn't have > regressions elsewhere until we reach gcc-9, for which I cannot find good > pre-built toolchains. We can get gcc-8.3 (or 8.2? I forget) from Arm > Ltd now, but that has problems on x86. Thanks for the background Tom, I wondered about the reasons behind. Regards, Andreas -- Andreas Dannenberg Texas Instruments Inc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL
On Thu, Jul 11, 2019 at 01:12:16PM -0500, Andreas Dannenberg wrote: > Yamada-san, > > On Fri, Jul 12, 2019 at 02:29:02AM +0900, Masahiro Yamada wrote: > > On Fri, Jul 12, 2019 at 12:34 AM Andreas Dannenberg > > wrote: > > > > > > On Wed, Jul 10, 2019 at 04:30:44PM -0500, Andreas Dannenberg wrote: > > > > On several platforms space is very tight when building for SPL or TPL. > > > > To claw back a few bytes to be used for code remove the __FILE__ name > > > > from the BUG() and WARN() type macros. Since those macros still print > > > > the function name plus a line number this should not really affect > > > > the ability to backtrace an actual BUG/WARN message to a specific > > > > piece of code. > > > > > > > > Signed-off-by: Andreas Dannenberg > > > > --- > > > > > > > > I was looking for a way to shave off a few bytes from the SPL code size > > > > (TI AM335x) and looking at the hexdump of the SPL I found well why not > > > > further reduce some strings down in size... I was already aware of the > > > > recent compiler optimizations to drop some of the irrelevant path from > > > > the __FILE__ macro but I wanted to go one step beyond this. Dropping > > > > all the path from __FILE__ via preprocessor macro can't be easily done > > > > as others have already found so I decided to drop __FILE__ altogether > > > > (code below) and was excited about the improvements I got... > > > > > > Just some quick examples about the savings... > > > > > > Using buildman "bloat" reporting (-B) I see the SPL .text size for AM335x > > > to be reduced by 12 bytes. And for AM43xx the size goes down by 52 > > > bytes. The benefit of the proposed change really depends on a) whether a > > > given platform uses SPL, and b) how many calls to BUG/WARN it has. The > > > USB drivers in AM335x/AM43xx are really the "heavy hitters" here. I'm > > > sure I could find additional examples/platforms to highlight savings if > > > needed. > > > > > > Anyways I'm not proud of the proposed change but merely wanted to see > > > with this RFC if there isn't any way to do further optimizations on the > > > __FILE__ topic that are not overly intrusive specifically as it comes to > > > SPL. > > > > > > Commit 1eb2e71edd55e16562e3912881c449db69623352 > > was not enough to solve your problem. > > > > Correct? > > Correct. This is a great commit and I saw what all went into it and it > goes a long way in addressing the general concern and doing much needed > cleanup but I wanted to go beyond this. > > Consider this example, if I use a WARN_ON() deep in the arch folder of > one of the SoCs, I would get this on the console... > > WARNING at arch/arm/mach-k3/am6_init.c:192/board_init_f()! > > ...and now, with the proposed change, it would boil down to this... > > WARNING at 192@board_init_f()! > > > If we could just keep the base filename itself that would still be a > good size reduction, and keep the output somewhat consistent with the > original behavior, but I spent quite some time researching but without > some extreme "magic" there didn't seem to be an universal solution... > > > Also some additional background why I am even looking into this. One of > our platforms (AM335x) has a regression building on Travis CI with some > of our pending patches applied. Interestingly, this only happens on > Travis, which still uses GCC 7.3.0 for arm (why?). With newer, more > efficient compilers there is no such issue. On this last point, gcc 7.3 is the current GCC release that doesn't have regressions elsewhere until we reach gcc-9, for which I cannot find good pre-built toolchains. We can get gcc-8.3 (or 8.2? I forget) from Arm Ltd now, but that has problems on x86. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL
Yamada-san, On Fri, Jul 12, 2019 at 02:29:02AM +0900, Masahiro Yamada wrote: > On Fri, Jul 12, 2019 at 12:34 AM Andreas Dannenberg wrote: > > > > On Wed, Jul 10, 2019 at 04:30:44PM -0500, Andreas Dannenberg wrote: > > > On several platforms space is very tight when building for SPL or TPL. > > > To claw back a few bytes to be used for code remove the __FILE__ name > > > from the BUG() and WARN() type macros. Since those macros still print > > > the function name plus a line number this should not really affect > > > the ability to backtrace an actual BUG/WARN message to a specific > > > piece of code. > > > > > > Signed-off-by: Andreas Dannenberg > > > --- > > > > > > I was looking for a way to shave off a few bytes from the SPL code size > > > (TI AM335x) and looking at the hexdump of the SPL I found well why not > > > further reduce some strings down in size... I was already aware of the > > > recent compiler optimizations to drop some of the irrelevant path from > > > the __FILE__ macro but I wanted to go one step beyond this. Dropping > > > all the path from __FILE__ via preprocessor macro can't be easily done > > > as others have already found so I decided to drop __FILE__ altogether > > > (code below) and was excited about the improvements I got... > > > > Just some quick examples about the savings... > > > > Using buildman "bloat" reporting (-B) I see the SPL .text size for AM335x > > to be reduced by 12 bytes. And for AM43xx the size goes down by 52 > > bytes. The benefit of the proposed change really depends on a) whether a > > given platform uses SPL, and b) how many calls to BUG/WARN it has. The > > USB drivers in AM335x/AM43xx are really the "heavy hitters" here. I'm > > sure I could find additional examples/platforms to highlight savings if > > needed. > > > > Anyways I'm not proud of the proposed change but merely wanted to see > > with this RFC if there isn't any way to do further optimizations on the > > __FILE__ topic that are not overly intrusive specifically as it comes to > > SPL. > > > Commit 1eb2e71edd55e16562e3912881c449db69623352 > was not enough to solve your problem. > > Correct? Correct. This is a great commit and I saw what all went into it and it goes a long way in addressing the general concern and doing much needed cleanup but I wanted to go beyond this. Consider this example, if I use a WARN_ON() deep in the arch folder of one of the SoCs, I would get this on the console... WARNING at arch/arm/mach-k3/am6_init.c:192/board_init_f()! ...and now, with the proposed change, it would boil down to this... WARNING at 192@board_init_f()! If we could just keep the base filename itself that would still be a good size reduction, and keep the output somewhat consistent with the original behavior, but I spent quite some time researching but without some extreme "magic" there didn't seem to be an universal solution... Also some additional background why I am even looking into this. One of our platforms (AM335x) has a regression building on Travis CI with some of our pending patches applied. Interestingly, this only happens on Travis, which still uses GCC 7.3.0 for arm (why?). With newer, more efficient compilers there is no such issue. -- Andreas Dannenberg Texas Instruments Inc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] fit: Support compression for non-kernel components (e.g. FDT)
On Wed, May 15, 2019 at 03:29:57PM -0700, Julius Werner wrote: > This patch adds support for compressing non-kernel image nodes in a FIT > image (kernel nodes could already be compressed previously). This can > reduce the size of FIT images and therefore improve boot times > (especially when an image bundles many different kernel FDTs). The > images will automatically be decompressed on load. > > This patch does not support extracting compatible strings from > compressed FDTs, so it's not very helpful in conjunction with > CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments > that select the configuration to load explicitly. > > Signed-off-by: Julius Werner > Reviewed-by: Simon Glass This breaks tools-only_defconfig in non-trivial ways due to calling bootm_decomp_image() which is not normally available to it. Can you please update things (it may just end up being common/Makefile that needs tweaking) so that tools-only builds? I'll then take a look and make sure we don't also see unexpected size growth elsewhere. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] board: Add support for iMXQXP AI_ML board
This commit adds initial board support for iMXQXP AI_ML board from Einfochips. This board is one of the 96Boards Consumer Edition and AI boards of the 96Boards family based on i.MXQXP SoC from NXP/Freescale. This initial supports contains following peripherals which are tested and known to work: 1. Debug serial via UART2 2. SD card 3. Ethernet More information about this board can be found in arrow website: https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools Signed-off-by: Manivannan Sadhasivam --- arch/arm/mach-imx/imx8/Kconfig| 6 + board/einfochips/imx8qxp_ai_ml/Kconfig| 12 ++ board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + board/einfochips/imx8qxp_ai_ml/Makefile | 8 + board/einfochips/imx8qxp_ai_ml/README | 49 ++ .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 128 ++ board/einfochips/imx8qxp_ai_ml/imximage.cfg | 24 +++ board/einfochips/imx8qxp_ai_ml/spl.c | 59 +++ configs/imx8qxp_ai_ml_defconfig | 83 + include/configs/imx8qxp_ai_ml.h | 157 ++ 10 files changed, 532 insertions(+) create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile create mode 100644 board/einfochips/imx8qxp_ai_ml/README create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c create mode 100644 configs/imx8qxp_ai_ml_defconfig create mode 100644 include/configs/imx8qxp_ai_ml.h diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig index bbe323d5ca..cec21f8dd2 100644 --- a/arch/arm/mach-imx/imx8/Kconfig +++ b/arch/arm/mach-imx/imx8/Kconfig @@ -37,6 +37,11 @@ config TARGET_COLIBRI_IMX8X select BOARD_LATE_INIT select IMX8QXP +config TARGET_IMX8QXP_AI_ML + bool "Support i.MX8QXP AI_ML board" + select BOARD_LATE_INIT + select IMX8QXP + config TARGET_IMX8QM_MEK bool "Support i.MX8QM MEK board" select BOARD_LATE_INIT @@ -49,6 +54,7 @@ config TARGET_IMX8QXP_MEK endchoice +source "board/einfochips/imx8qxp_ai_ml/Kconfig" source "board/freescale/imx8qm_mek/Kconfig" source "board/freescale/imx8qxp_mek/Kconfig" source "board/toradex/apalis-imx8/Kconfig" diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig b/board/einfochips/imx8qxp_ai_ml/Kconfig new file mode 100644 index 00..697a831013 --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig @@ -0,0 +1,12 @@ +if TARGET_IMX8QXP_AI_ML + +config SYS_BOARD + default "imx8qxp_ai_ml" + +config SYS_VENDOR + default "einfochips" + +config SYS_CONFIG_NAME + default "imx8qxp_ai_ml" + +endif diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS new file mode 100644 index 00..add0bd9431 --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS @@ -0,0 +1,6 @@ +i.MX8QXP AI_ML BOARD +M: Manivannan Sadhasivam +S: Maintained +F: board/einfochips/imx8qxp_ai_ml/ +F: include/configs/imx8qxp_ai_ml.h +F: configs/imx8qxp_ai_ml_defconfig diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile b/board/einfochips/imx8qxp_ai_ml/Makefile new file mode 100644 index 00..e08774dc6e --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/Makefile @@ -0,0 +1,8 @@ +# +# Copyright 2019 Linaro Ltd. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += imx8qxp_ai_ml.o +obj-$(CONFIG_SPL_BUILD) += spl.o diff --git a/board/einfochips/imx8qxp_ai_ml/README b/board/einfochips/imx8qxp_ai_ml/README new file mode 100644 index 00..416a157ea8 --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/README @@ -0,0 +1,49 @@ +U-Boot for the Einfochips i.MX8QXP AI_ML board + +Quick Start +=== + +- Build the ARM Trusted firmware binary +- Get scfw_tcm.bin and ahab-container.img +- Build U-Boot +- Flash the binary into the SD card +- Boot + +Get and Build the ARM Trusted firmware +== + +$ git clone https://source.codeaurora.org/external/imx/imx-atf +$ cd imx-atf/ +$ git checkout origin/imx_4.9.88_imx8qxp_beta2 -b imx_4.9.88_imx8qxp_beta2 +$ make PLAT=imx8qxp bl31 + +Get scfw_tcm.bin and ahab-container.img +=== + +$ wget https://raw.githubusercontent.com/96boards-ai-ml/binaries/master/mx8qx-aiml-scfw-tcm.bin +$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.1.bin +$ chmod +x firmware-imx-8.1.bin +$ ./firmware-imx-8.1.bin + +Copy the following binaries to U-Boot folder: + +$ cp imx-atf/build/imx8qxp/release/bl31.bin . +$ cp firmware-imx-8.1/firmware/seco/mx8qx-ahab-container.img . + +Build U-Boot + + +$ make imx8qxp_ai_ml_defconfig +$ make u-boot-dtb.imx + +Flash the binary into the SD card +=
[U-Boot] [PATCH v2 1/2] arm: dts: Add devicetree support for iMXQXP AI_ML board
Add devicetree support for iMXQXP AI_ML board from Einfochips.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi | 117 +
arch/arm/dts/fsl-imx8qxp-ai_ml.dts | 181 +
3 files changed, 299 insertions(+)
create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e6680e5e98..7834a158da 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -614,6 +614,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
+ fsl-imx8qxp-ai_ml.dtb \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
diff --git a/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
b/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
new file mode 100644
index 00..3ca53bb945
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Linaro Ltd.
+ */
+
+&{/imx8qx-pm} {
+
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_lsio {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio0 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio1 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio2 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio3 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio4 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio5 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio6 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio7 {
+ u-boot,dm-spl;
+};
+
+_conn {
+ u-boot,dm-spl;
+};
+
+_conn_sdch0 {
+ u-boot,dm-spl;
+};
+
+_conn_sdch1 {
+ u-boot,dm-spl;
+};
+
+_conn_sdch2 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
b/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
new file mode 100644
index 00..aa85caaff5
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 Einfochips
+ * Copyright 2019 Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include "fsl-imx8qxp.dtsi"
+#include "fsl-imx8qxp-ai_ml-u-boot.dtsi"
+
+/ {
+ model = "Einfochips i.MX8QXP AI_ML";
+ compatible = "einfochips,imx8qxp-ai_ml", "fsl,imx8qxp";
+
+ chosen {
+ bootargs = "console=ttyLP2,115200
earlycon=lpuart32,0x5a08,115200";
+ stdout-path =
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x 0x8000 0 0x8000>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart0>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart2>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart3>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_fec1>;
+ phy-mode = "rgmii";
+ phy-handle = <>;
+ fsl,ar8031-phy-fixup;
+ fsl,magic-packet;
+ phy-reset-gpios = < 14 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
+ phy-reset-post-delay = <150>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
+};
+
+/* LS-I2C1 */
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpi2c1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc1>;
+ bus-width = <4>;
+ no-sd;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc2>;
+ bus-width = <4>;
+ cd-gpios = < 22 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+ {
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB0_PAD
0x14a0
+ SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB1_PAD
0x14a0
+ SC_P_ENET0_MDC_CONN_ENET0_MDC
0x0620
+ SC_P_ENET0_MDIO_CONN_ENET0_MDIO
[U-Boot] [PATCH v2 0/2] Add board support for iMX8QXP AI_ML board
Hello, This patchset adds initial board support for iMX8QXP AI_ML board from Einfochips. This board is one of the Consumer Edition and AI boards of the 96Boards family. This initial supports contains following peripherals which are tested and known to work: 1. Debug serial via UART2 2. SD card 3. Ethernet Thanks, Mani Note: This patchset depends on the below cleanup patches submitted: [U-Boot,1/2] arm: imx8: factor out uart init code [U-Boot,2/2] arm: imx8: don't duplicate build_info() Changes in v2: * Rebased the patches on top of following patches: [U-Boot,1/2] arm: imx8: factor out uart init code [U-Boot,2/2] arm: imx8: don't duplicate build_info() Manivannan Sadhasivam (2): arm: dts: Add devicetree support for iMXQXP AI_ML board board: Add support for iMXQXP AI_ML board arch/arm/dts/Makefile | 1 + arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi| 117 +++ arch/arm/dts/fsl-imx8qxp-ai_ml.dts| 181 ++ arch/arm/mach-imx/imx8/Kconfig| 6 + board/einfochips/imx8qxp_ai_ml/Kconfig| 12 ++ board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + board/einfochips/imx8qxp_ai_ml/Makefile | 8 + board/einfochips/imx8qxp_ai_ml/README | 49 + .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 128 + board/einfochips/imx8qxp_ai_ml/imximage.cfg | 24 +++ board/einfochips/imx8qxp_ai_ml/spl.c | 59 ++ configs/imx8qxp_ai_ml_defconfig | 83 include/configs/imx8qxp_ai_ml.h | 157 +++ 13 files changed, 831 insertions(+) create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml.dts create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile create mode 100644 board/einfochips/imx8qxp_ai_ml/README create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c create mode 100644 configs/imx8qxp_ai_ml_defconfig create mode 100644 include/configs/imx8qxp_ai_ml.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL
On Fri, Jul 12, 2019 at 12:34 AM Andreas Dannenberg wrote: > > On Wed, Jul 10, 2019 at 04:30:44PM -0500, Andreas Dannenberg wrote: > > On several platforms space is very tight when building for SPL or TPL. > > To claw back a few bytes to be used for code remove the __FILE__ name > > from the BUG() and WARN() type macros. Since those macros still print > > the function name plus a line number this should not really affect > > the ability to backtrace an actual BUG/WARN message to a specific > > piece of code. > > > > Signed-off-by: Andreas Dannenberg > > --- > > > > I was looking for a way to shave off a few bytes from the SPL code size > > (TI AM335x) and looking at the hexdump of the SPL I found well why not > > further reduce some strings down in size... I was already aware of the > > recent compiler optimizations to drop some of the irrelevant path from > > the __FILE__ macro but I wanted to go one step beyond this. Dropping > > all the path from __FILE__ via preprocessor macro can't be easily done > > as others have already found so I decided to drop __FILE__ altogether > > (code below) and was excited about the improvements I got... > > Just some quick examples about the savings... > > Using buildman "bloat" reporting (-B) I see the SPL .text size for AM335x > to be reduced by 12 bytes. And for AM43xx the size goes down by 52 > bytes. The benefit of the proposed change really depends on a) whether a > given platform uses SPL, and b) how many calls to BUG/WARN it has. The > USB drivers in AM335x/AM43xx are really the "heavy hitters" here. I'm > sure I could find additional examples/platforms to highlight savings if > needed. > > Anyways I'm not proud of the proposed change but merely wanted to see > with this RFC if there isn't any way to do further optimizations on the > __FILE__ topic that are not overly intrusive specifically as it comes to > SPL. Commit 1eb2e71edd55e16562e3912881c449db69623352 was not enough to solve your problem. Correct? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] fastboot: Implement fetching uboot env variables via fastboot getvar
Hi Priit,
On Wed, Jul 10, 2019 at 11:42 AM Eugeniu Rosca wrote:
>
> Hi Priit,
>
> On Tue, Jul 09, 2019 at 02:52:56PM +0300, Priit Laes wrote:
> > From: Priit Laes
> >
> > Add u-boot specific getvar "extension" to fetch u-boot environment
> > variables via `fastboot getvar uboot:var`. This makes it possible
> > to gather certain data (like mac addresses) in an automated way
> > during initial fastboot flashing for inventory purposes:
> >
> > $ fastboot getvar uboot:ethaddr
> > uboot:ethaddr: 12:23:45:56:78:90
> >
> > Output is currently truncated at 64 bytes, but this is good enough
> > for my own requirements.
> >
> > Signed-off-by: Priit Laes
> > ---
> > drivers/fastboot/fb_getvar.c | 14 ++
>
> [..]
>
> > +static void getvar_ubootenv(char *var_parameter, char *response)
> > +{
> > + const char *value = env_get(var_parameter);
>
> This would bring a lot of flexibility to the users. My only concern is
> that it exposes to the outside world an internal U-Boot API (env_get)
> which might have weaknesses (or might acquire them in time). I am not
> sure how env_get() behaves in below corner cases:
> - NULL pointer
> - empty string
> - hugely long string
>
> IMHO the internal APIs are usually not designed to sustain high level of
> stress/fuzziness in their input parameters. Once made available to the
> users of fastboot tool, this will open room for more experiments to the
> CVE seekers.
>
> Another observation is that this patch will contribute with a deviation
> from the vanilla fastboot protocol (which might be fine).
>
> Since there are already multiple getvar functions which fetch the
> information from the U-Boot environment, I wonder if all of these could
> be centralized in a table like below:
>
> {
> /* fastbootU-Boot */
> { "serialno", "serial#" },
> { "product", "board" },
> { "platform", "platform" },
> { "ethaddr", "ethaddr" },
> { "anything", "anything" },
> }
>
> The upsides of this approach:
> - Unification, readability, decreased code size
> The downsides:
> - Inflexible for getting arbitrary environment variables
>
I agree with Eugeniu on his points about security and deviation from
fastboot spec (can be found in AOSP). Instead of exposing the whole
U-Boot environment, I can suggest you to expose only actually needed
variables for your platform. In fact, we already have a mechanism
exactly for that, called "variable overrides". It's documented in [1].
Basically you just need to add "fastboot.xxx" variables to your
environment (can be don e.g. in your board_late_init() function), and
you'll be able to obtain those via "fastboot getvar xxx". You can see
an example in patches [2,3].
[1]
https://gitlab.denx.de/u-boot/u-boot/blob/v2019.07/doc/README.android-fastboot#L90
[2]
https://gitlab.denx.de/u-boot/u-boot/commit/fa24eca1f20a037d2dcbd1eae7ac8b2ecb1b0423
[3]
https://gitlab.denx.de/u-boot/u-boot/commit/8bd29623b5223e880e7be475243a2bdb987aba38
> --
> Best Regards,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom,
I picked up a different patch for the unicode handling.
Passing build here:
https://travis-ci.org/sglass68/u-boot/builds/557041198
The following changes since commit ef8b7e045ec744dce385cac4b1438c9be6e2bbc8:
Merge https://gitlab.denx.de/u-boot/custodians/u-boot-i2c (2019-07-10
13:51:53 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-dm.git tags/dm-pull-9jul19-take2
for you to fetch changes up to 7ea33579576d2bcd19df76bd8769e7ab3b4a169b:
trace: trace buffer may exceed 2GiB (2019-07-10 16:52:58 -0600)
- Sandbox improvements including .dts refactor
- Minor tracing and PCI improvements
- Various other minor fixes
- Conversion of patman, dtoc and binman to support Python 3
Alex Marginean (4):
pci: fixed dm_pci_map_bar comment
drivers: pci: add map_bar support for Enhanced Allocation
test: dm: Add a test for PCI Enhanced Allocation
drivers: pci: add API to issue FLR on a PCI function if supported
Heinrich Schuchardt (5):
trace: undefined reference to `trace_early_init'
trace: conserve gd register
trace: make call depth limit customizable
trace: do not limit trace buffer to 2GiB
trace: trace buffer may exceed 2GiB
Patrick Delaunay (3):
test: check u-boot properties in SPL device tree
fdt: Allow indicating a node is for U-Boot proper only
dm: doc: add documentation for pre-reloc properties in SPL and TPL
Simon Glass (60):
patman: Update cros_subprocess to use bytes
patman: Convert print statements to Python 3
binman: Convert print statements to Python 3
binman: Don't show errors for failed tests
binman: Remove use of Set()
patman: Use items() instead of iteritems()
binman: Use items() instead of iteritems()
tools: binman: Open all binary files in binary mode
tools: dtoc: Open all binary files in binary mode
patman: Provide a way to get program output in binary mode
binman: Use binary mode when compressing data
binman: Drop an unused input file
binman: Handle repeated bytes for Python 3
patman: Support use of stringIO in Python 3
patman: Move unicode helpers to tools
patman: Sort series output for repeatabily
patman: Avoid unicode type in settings unit tests
patman: Adjust functional tests for Python 3
patman: Tidy up a few more unicode conversions
patman: Don't require Python 2
dtoc: Adjust code for Python 3
dtoc: Sort platdata output from dtoc
dtoc: Use GetBytes() to obtain repeating bytes
dtoc: Move BytesToValue() out of the Prop class
dtoc: Updates BytesToValue() for Python 3
dtoc: Use byte type instead of str in fdt
dtoc: Convert the Fdt.Prop class to Python 3
dtoc: Convert the Fdt.Node class to Python 3
dtoc: Use binary mode for reading files
dtoc: Test full 64-bit properties with FdtCellsToCpu()
dtoc: Add a unit test for BytesToValue()
dtoc: Update fdt_util for Python 3
dtoc: Update dtb_platdata to support Python 3
patman: Allow reading files in text mode
binman: Avoid changing a dict during iteration
binman: Convert to use bytes type
binman: Update entry_test to support Python 3
patman: Update fmap code for Python 3
binman: Update 'text' entry for Python 3
binman: Fix up a format string in AssertInList()
binman: Read map files as text
binman: Document parallel tests
binman: Update the README.entries file
patman: Update cover-coverage tests for Python 3
Add a simple script to remove boards
sandbox: Sync up sandbox64.dts with main DT
sandbox: Create a common sandbox DT
sandbox: Add an alias for SPI
sandbox: Exit when SYSRESET_POWER_OFF is requested
sandbox: Quit when hang() is called
sandbox: spl: Lower priority of standard loader
sandbox: Add a comment to board_init_f()
sandbox: Allo sdl-config to be overridden
sandbox: Add a memory {} node
sandbox: Correct spi flash operation
sandbox: Add documentation on how to run valgrind
x86: Add a forward struct declaration in coreboot_tables.h
bootstage: Add support for TPL record count
blk: Allow control of the block cache in TPL
spi: Avoid using malloc() in a critical function
Thierry Reding (1):
fdtdec: test: Fix memory leak
Vabhav Sharma (1):
drivers: serial: lpuart: Enable Little Endian Support
arch/sandbox/config.mk | 5 +-
arch/sandbox/cpu/spl.c | 3 +-
arch/sandbox/cpu/state.c| 1 +
arch/sandbox/dts/sandbox.dts| 336
+--
arch/sandbox/dts/sandbox.dtsi | 364
Re: [U-Boot] [PATCH v2 01/21] patman: Update cros_subprocess to use bytes
On Wed, 10 Jul 2019 at 16:51, Simon Glass wrote: > > At present this function uses lists and strings. This does not work so > well with Python 3, and testing against '' does not work for a bytearray. > Update the code to fix these issues. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Update to use bytes instead of bytearray > > tools/patman/cros_subprocess.py | 47 +++-- > tools/patman/gitutil.py | 2 ++ > 2 files changed, 29 insertions(+), 20 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
Hi Tom, On Wed, 10 Jul 2019 at 08:39, Tom Rini wrote: > > On Tue, Jul 09, 2019 at 11:16:18AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > Build is here: > > > > https://travis-ci.org/sglass68/u-boot/builds/556001438 > > > > (looks like there is a unicode issue I need to look at) > > > > The following changes since commit e5aee22e4be75e75a854ab64503fc80598bc2004: > > > > Prepare v2019.07 (2019-07-08 15:23:28 -0400) > > > > are available in the Git repository at: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-9jul19 > > > > for you to fetch changes up to b7eb801e0e6bdf42a592087a797deda1b0f03d69: > > > > trace: trace buffer may exceed 2GiB (2019-07-08 15:23:09 -0600) > > > > Since that unicode problem fails travis, I do need that fixed before I > can take this, thanks! Ah yes. I saw the timeout and thought it was some sort of infra problem, but of course it is buildman. I'll send a new email. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] board: puma: Use rockchip_* helpers to setup cpuid and macaddr
> On 11.07.2019, at 18:28, Rohan Garg wrote: > > Signed-off-by: Rohan Garg Your commit message is empty on this one. Please revise. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: use predefined constants in crt0_*_efi.S
We should use predefined constants instead of magic numbers. Move some constant definitions from include/pe.h to include/asm-generic/pe.h. Use these constants in crt0_*_efi.S. Signed-off-by: Heinrich Schuchardt --- arch/arm/lib/crt0_aarch64_efi.S | 9 - arch/arm/lib/crt0_arm_efi.S | 9 - arch/riscv/lib/crt0_riscv_efi.S | 11 +-- include/asm-generic/pe.h| 16 include/pe.h| 15 --- 5 files changed, 29 insertions(+), 31 deletions(-) diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S index cb205fa30a..368933ecf2 100644 --- a/arch/arm/lib/crt0_aarch64_efi.S +++ b/arch/arm/lib/crt0_aarch64_efi.S @@ -17,14 +17,13 @@ */ .globl ImageBase ImageBase: - .ascii "MZ" + .short IMAGE_DOS_SIGNATURE /* 'MZ' */ .skip 58 /* 'MZ' + pad + offset == 64 */ .long pe_header - ImageBase /* Offset to the PE header */ pe_header: - .ascii "PE" - .short 0 + .long IMAGE_NT_SIGNATURE /* 'PE' */ coff_header: - .short 0xaa64 /* AArch64 */ + .short IMAGE_FILE_MACHINE_ARM64/* AArch64 */ .short 2 /* nr_sections */ .long 0 /* TimeDateStamp */ .long 0 /* PointerToSymbolTable */ @@ -36,7 +35,7 @@ coff_header: IMAGE_FILE_LOCAL_SYMS_STRIPPED | \ IMAGE_FILE_DEBUG_STRIPPED) optional_header: - .short 0x20b /* PE32+ format */ + .short IMAGE_NT_OPTIONAL_HDR64_MAGIC /* PE32+ format */ .byte 0x02/* MajorLinkerVersion */ .byte 0x14/* MinorLinkerVersion */ .long _edata - _start /* SizeOfCode */ diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S index 5470e2ff0e..cc8a115f31 100644 --- a/arch/arm/lib/crt0_arm_efi.S +++ b/arch/arm/lib/crt0_arm_efi.S @@ -16,14 +16,13 @@ */ .globl image_base image_base: - .ascii "MZ" + .short IMAGE_DOS_SIGNATURE /* 'MZ' */ .skip 58 /* 'MZ' + pad + offset == 64 */ .long pe_header - image_base /* Offset to the PE header */ pe_header: - .ascii "PE" - .short 0 + .long IMAGE_NT_SIGNATURE /* 'PE' */ coff_header: - .short 0x1c2 /* Mixed ARM/Thumb */ + .short IMAGE_FILE_MACHINE_THUMB/* Mixed ARM/Thumb */ .short 2 /* nr_sections */ .long 0 /* TimeDateStamp */ .long 0 /* PointerToSymbolTable */ @@ -36,7 +35,7 @@ coff_header: IMAGE_FILE_32BIT_MACHINE | \ IMAGE_FILE_DEBUG_STRIPPED) optional_header: - .short 0x10b /* PE32 format */ + .short IMAGE_NT_OPTIONAL_HDR32_MAGIC /* PE32 format */ .byte 0x02/* MajorLinkerVersion */ .byte 0x14/* MinorLinkerVersion */ .long _edata - _start /* SizeOfCode */ diff --git a/arch/riscv/lib/crt0_riscv_efi.S b/arch/riscv/lib/crt0_riscv_efi.S index b7b5329e1f..87fe1e56f9 100644 --- a/arch/riscv/lib/crt0_riscv_efi.S +++ b/arch/riscv/lib/crt0_riscv_efi.S @@ -14,12 +14,12 @@ #define SIZE_LONG 8 #define SAVE_LONG(reg, idx)sd reg, (idx*SIZE_LONG)(sp) #define LOAD_LONG(reg, idx)ld reg, (idx*SIZE_LONG)(sp) -#define PE_MACHINE 0x5064 +#define PE_MACHINE IMAGE_FILE_MACHINE_RISCV64 #else #define SIZE_LONG 4 #define SAVE_LONG(reg, idx)sw reg, (idx*SIZE_LONG)(sp) #define LOAD_LONG(reg, idx)lw reg, (idx*SIZE_LONG)(sp) -#define PE_MACHINE 0x5032 +#define PE_MACHINE IMAGE_FILE_MACHINE_RISCV32 #endif @@ -30,12 +30,11 @@ */ .globl ImageBase ImageBase: - .ascii "MZ" + .short IMAGE_DOS_SIGNATURE /* 'MZ' */ .skip 58 /* 'MZ' + pad + offset == 64 */ .long pe_header - ImageBase /* Offset to the PE header */ pe_header: - .ascii "PE" - .short 0 + .long IMAGE_NT_SIGNATURE /* 'PE' */ coff_header: .short PE_MACHINE /* RISC-V 64/32-bit */ .short 2 /* nr_sections */ @@ -49,7 +48,7 @@ coff_header: IMAGE_FILE_LOCAL_SYMS_STRIPPED | \ IMAGE_FILE_DEBUG_STRIPPED) optional_header: - .short 0x20b /* PE32+ format */ + .short IMAGE_NT_OPTIONAL_HDR64_MAGIC /* PE32+ format */ .byte 0x02
[U-Boot] [PATCH 1/3] rockchip: rk3399: derive ethaddr from cpuid
Generate a MAC address based on the cpuid available in the efuse
block: Use the first 6 byte of the cpuid's SHA256 hash and set the
locally administered bits. Also ensure that the multicast bit is
cleared.
The MAC address is only generated and set if there is no ethaddr
present in the saved environment.
This is based off of Klaus Goger's work in 8adc9d
Signed-off-by: Rohan Garg
---
arch/arm/include/asm/arch-rockchip/misc.h | 13 +++
arch/arm/mach-rockchip/Makefile | 2 +
arch/arm/mach-rockchip/misc.c | 108 ++
board/rockchip/evb_rk3399/evb-rk3399.c| 13 +++
4 files changed, 136 insertions(+)
create mode 100644 arch/arm/include/asm/arch-rockchip/misc.h
create mode 100644 arch/arm/mach-rockchip/misc.c
diff --git a/arch/arm/include/asm/arch-rockchip/misc.h
b/arch/arm/include/asm/arch-rockchip/misc.h
new file mode 100644
index 00..11ca4eb033
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/misc.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * RK3399: Architecture common definitions
+ *
+ * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
+ * Rohan Garg
+ */
+
+void rockchip_cpuid_from_efuse(const u32 cpuid_offset,
+ const u32
cpuid_length,
+ u8 *cpuid);
+void rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length);
+void rockchip_setup_macaddr(void);
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 23760a959a..43d895564f 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -47,6 +47,8 @@ obj-y += rk_timer.o
endif
endif
+obj-y += misc.o
+
obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
ifndef CONFIG_TPL_BUILD
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
new file mode 100644
index 00..e2d9dec817
--- /dev/null
+++ b/arch/arm/mach-rockchip/misc.c
@@ -0,0 +1,108 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * RK3399: Architecture common definitions
+ *
+ * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
+ * Rohan Garg
+ *
+ * Based on puma-rk3399.c:
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+void rockchip_setup_macaddr(void)
+{
+#if CONFIG_IS_ENABLED(CMD_NET)
+ int ret;
+ const char *cpuid = env_get("cpuid#");
+ u8 hash[SHA256_SUM_LEN];
+ int size = sizeof(hash);
+ u8 mac_addr[6];
+
+ /* Only generate a MAC address, if none is set in the environment */
+ if (env_get("ethaddr"))
+ return;
+
+ if (!cpuid) {
+ debug("%s: could not retrieve 'cpuid#'\n", __func__);
+ return;
+ }
+
+ ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, );
+ if (ret) {
+ debug("%s: failed to calculate SHA256\n", __func__);
+ return;
+ }
+
+ /* Copy 6 bytes of the hash to base the MAC address on */
+ memcpy(mac_addr, hash, 6);
+
+ /* Make this a valid MAC address and set it */
+ mac_addr[0] &= 0xfe; /* clear multicast bit */
+ mac_addr[0] |= 0x02; /* set local assignment bit (IEEE802) */
+ eth_env_set_enetaddr("ethaddr", mac_addr);
+#endif
+}
+
+void rockchip_cpuid_from_efuse(const u32 cpuid_offset,
+ const u32
cpuid_length,
+ u8 *cpuid)
+{
+#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
+ struct udevice *dev;
+ int ret;
+
+ /* retrieve the device */
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_GET_DRIVER(rockchip_efuse), );
+ if (ret) {
+ debug("%s: could not find efuse device\n", __func__);
+ return;
+ }
+
+ /* read the cpu_id range from the efuses */
+ ret = misc_read(dev, cpuid_offset, cpuid, sizeof(cpuid));
+ if (ret) {
+ debug("%s: reading cpuid from the efuses failed\n",
+ __func__);
+ return;
+ }
+#endif
+}
+
+void rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
+{
+u8 low[cpuid_length/2], high[cpuid_length/2];
+ char cpuid_str[cpuid_length * 2 + 1];
+ u64 serialno;
+ char serialno_str[17];
+ int i;
+
+memset(cpuid_str, 0, sizeof(cpuid_str));
+ for (i = 0; i < 16; i++)
+ sprintf(_str[i * 2], "%02x", cpuid[i]);
+
+ debug("cpuid: %s\n", cpuid_str);
+
+ /*
+* Mix the cpuid bytes using the same rules as in
+* ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
+*/
+ for (i = 0; i < 8; i++) {
+ low[i] = cpuid[1 + (i << 1)];
+ high[i] =
[U-Boot] [PATCH 3/3] board: puma: Use rockchip_* helpers to setup cpuid and macaddr
Signed-off-by: Rohan Garg
---
.../puma_rk3399/puma-rk3399.c | 98 ++-
1 file changed, 8 insertions(+), 90 deletions(-)
diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 251cd2d566..af94ed998a 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,94 +37,6 @@ int board_init(void)
return 0;
}
-static void setup_macaddr(void)
-{
-#if CONFIG_IS_ENABLED(CMD_NET)
- int ret;
- const char *cpuid = env_get("cpuid#");
- u8 hash[SHA256_SUM_LEN];
- int size = sizeof(hash);
- u8 mac_addr[6];
-
- /* Only generate a MAC address, if none is set in the environment */
- if (env_get("ethaddr"))
- return;
-
- if (!cpuid) {
- debug("%s: could not retrieve 'cpuid#'\n", __func__);
- return;
- }
-
- ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, );
- if (ret) {
- debug("%s: failed to calculate SHA256\n", __func__);
- return;
- }
-
- /* Copy 6 bytes of the hash to base the MAC address on */
- memcpy(mac_addr, hash, 6);
-
- /* Make this a valid MAC address and set it */
- mac_addr[0] &= 0xfe; /* clear multicast bit */
- mac_addr[0] |= 0x02; /* set local assignment bit (IEEE802) */
- eth_env_set_enetaddr("ethaddr", mac_addr);
-#endif
-}
-
-static void setup_serial(void)
-{
-#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
- const u32 cpuid_offset = 0x7;
- const u32 cpuid_length = 0x10;
-
- struct udevice *dev;
- int ret, i;
- u8 cpuid[cpuid_length];
- u8 low[cpuid_length/2], high[cpuid_length/2];
- char cpuid_str[cpuid_length * 2 + 1];
- u64 serialno;
- char serialno_str[17];
-
- /* retrieve the device */
- ret = uclass_get_device_by_driver(UCLASS_MISC,
- DM_GET_DRIVER(rockchip_efuse), );
- if (ret) {
- debug("%s: could not find efuse device\n", __func__);
- return;
- }
-
- /* read the cpu_id range from the efuses */
- ret = misc_read(dev, cpuid_offset, , sizeof(cpuid));
- if (ret) {
- debug("%s: reading cpuid from the efuses failed\n",
- __func__);
- return;
- }
-
- memset(cpuid_str, 0, sizeof(cpuid_str));
- for (i = 0; i < 16; i++)
- sprintf(_str[i * 2], "%02x", cpuid[i]);
-
- debug("cpuid: %s\n", cpuid_str);
-
- /*
-* Mix the cpuid bytes using the same rules as in
-* ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
-*/
- for (i = 0; i < 8; i++) {
- low[i] = cpuid[1 + (i << 1)];
- high[i] = cpuid[i << 1];
- }
-
- serialno = crc32_no_comp(0, low, 8);
- serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
- snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
-
- env_set("cpuid#", cpuid_str);
- env_set("serial#", serialno_str);
-#endif
-}
-
static void setup_iodomain(void)
{
const u32 GRF_IO_VSEL_GPIO4CD_SHIFT = 3;
@@ -213,8 +126,13 @@ static int setup_boottargets(void)
int misc_init_r(void)
{
- setup_serial();
- setup_macaddr();
+ const u32 cpuid_offset = 0x7;
+ const u32 cpuid_length = 0x10;
+ u8 cpuid[cpuid_length];
+
+ rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
+ rockchip_cpuid_set(cpuid, cpuid_length);
+ rockchip_setup_macaddr();
setup_iodomain();
setup_boottargets();
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] rockchip: rk3399: Enable CONFIG_MISC_INIT_R for the Rock PI 4
This enables us to set a static MAC address Signed-off-by: Rohan Garg --- configs/rock-pi-4-rk3399_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index be670df23f..dc84ded86c 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -58,3 +58,4 @@ CONFIG_USB_ETHER_SMSC95XX=y CONFIG_USE_TINY_PRINTF=y CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y +CONFIG_MISC_INIT_R=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: duplicate IMAGE_SUBSYSTEM_EFI_APPLICATION
IMAGE_SUBSYSTEM_EFI_APPLICATION is already defined in
include/asm-generic/pe.h which is included in include/pe.h. We should
not define it twice.
Signed-off-by: Heinrich Schuchardt
---
include/pe.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/pe.h b/include/pe.h
index 36e1908b7e..c7aeb2dcb6 100644
--- a/include/pe.h
+++ b/include/pe.h
@@ -48,7 +48,6 @@ typedef struct _IMAGE_DOS_HEADER {
#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b
#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b
-#define IMAGE_SUBSYSTEM_EFI_APPLICATION10
typedef struct _IMAGE_FILE_HEADER {
uint16_t Machine;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] doc: bindings: Add description for MDIO MUX dts nodes
On Thu, Jul 11, 2019 at 2:07 AM Alex Marginean wrote: > > Adds a short bindings document describing the expected structure of a MDIO > MUX dts node. This is based on Linux binding and the example is in fact > copied from there. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] test: dm: add a test for MDIO MUX DM uclass
On Thu, Jul 11, 2019 at 2:08 AM Alex Marginean wrote: > > Adds a test using a makeshift MDIO MUX. The test is based on the existing > MDIO test. It uses the last emulated PHY register to verify MUX selection. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-marvell/master
Hi Tom, please pull the following Marvell related patches: - SPL SATA enhancements to allow booting from RAW SATA device needed for Clearfog (Baruch) - Enable SATA booting on Clearfog (Baruch) - Misc changes to Turris Omnia (Marek) - Enable CMD_BOOTZ and increase SYS_BOOTM_LEN on crs305-1g-4s (Luka) - Enable FIT support for db-xc3-24g4xg (Chris) - Enable DM_SPI on Keymile Kirkwood board with necessary changes for this (Pascal) - Set 38x and 39x AVS on lower frequency (Baruch) Here the Travis build, without any issues: https://travis-ci.org/stroese/u-boot/builds/557220799 Thanks, Stefan The following changes since commit ef8b7e045ec744dce385cac4b1438c9be6e2bbc8: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-i2c (2019-07-10 13:51:53 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to cc66ebdeeca5c4ed095bbd521b748bb009d99728: arm: mvebu: set 38x and 39x AVS on lower frequency (2019-07-11 10:58:03 +0200) Baruch Siach (9): spl: sata: add default partition and image name spl: sata: fix build with DM_SCSI spl: sata: don't force FS_FAT support arm: mvebu: fix ahci mbus config in SPL arm: mvebu: add support for boot from SATA arm: mvebu: clearfog: enable SATA in SPL arm: mvebu: clearfog: set U-Boot offset for SATA boot arm: mvebu: clearfog: document boot from SATA arm: mvebu: set 38x and 39x AVS on lower frequency Chris Packham (1): ARM: mvebu: Enable FIT support for db-xc3-24g4xg Luka Kovacic (1): arm: mvebu: crs305-1g-4s: Enable CMD_BOOTZ and increase SYS_BOOTM_LEN Marek Behún (7): arm: mvebu: turris_omnia: set default ethernet adapter arm: mvebu: turris_omnia: fix adapters MAC addresses arm: mvebu: turris_omnia: change environment address in SPI flash arm: mvebu: turris_omnia: remove unneeded macro from board config arm: mvebu: turris_omnia: prefer SCSI booting before USB arm: mvebu: turris_omnia: call pci_init from board init code arm: mvebu: turris_omnia: fix rescue mode bootcmd bootargs setting Pascal Linder (6): km: modify Kconfig file organization for KM boards km/spi: add weak functions to kirkwood_spi driver (DM part) km/spi: overwrite kirkwood_spi weak functions for KM Kirkwood boards km/spi: add SPI configuration to KM Kirkwood device tree km/spi: activate driver model for SPI flash on KM Kirkwood boards km/spi: remove deprecated SPI flash driver code for KM Kirkwood boards arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8 arch/arm/dts/kirkwood-km_kirkwood.dts | 22 ++ arch/arm/include/asm/arch-mvebu/spi.h | 11 - arch/arm/mach-kirkwood/Kconfig| 9 ++-- arch/arm/mach-mvebu/Kconfig | 5 +++ arch/arm/mach-mvebu/Makefile | 3 ++ arch/arm/mach-mvebu/cpu.c | 4 ++ arch/arm/mach-mvebu/include/mach/cpu.h| 7 +++ arch/arm/mach-mvebu/include/mach/soc.h| 2 + arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c | 26 +++ arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h | 4 ++ arch/arm/mach-mvebu/spl.c | 8 arch/powerpc/cpu/mpc83xx/Kconfig | 44 +-- arch/powerpc/cpu/mpc85xx/Kconfig | 8 +--- board/CZ.NIC/turris_omnia/turris_omnia.c | 10 +++-- board/keymile/Kconfig | 16 +++ board/keymile/km83xx/Kconfig | 62 +++ board/keymile/km_arm/Kconfig | 10 + board/keymile/km_arm/km_arm.c | 23 +- board/keymile/kmp204x/Kconfig | 8 board/solidrun/clearfog/README| 6 +++ common/spl/spl_sata.c | 20 +++-- configs/crs305-1g-4s_defconfig| 1 + configs/db-xc3-24g4xg_defconfig | 3 ++ configs/portl2_defconfig | 3 +- drivers/spi/kirkwood_spi.c| 52 +++--- include/configs/clearfog.h| 2 +- include/configs/crs305-1g-4s.h| 1 + include/configs/km/km_arm.h | 5 --- include/configs/turris_omnia.h| 12 ++ scripts/config_whitelist.txt | 1 - 31 files changed, 279 insertions(+), 117 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] board: Arcturus: ucp1020: Removing obsoleted stuff
Removed one of the defconfig(obsoleted) file and unused CONFIG_MMC_SPI definition to avoid confusion about if this board using non-DM stuff or not. uCP1020 is completely DM free board, tested and runs well. Signed-off-by: Oleksandr Zhadan Signed-off-by: Michael Durrant --- configs/UCP1020_SPIFLASH_defconfig | 60 -- include/configs/UCP1020.h | 1 - 2 files changed, 61 deletions(-) delete mode 100644 configs/UCP1020_SPIFLASH_defconfig diff --git a/configs/UCP1020_SPIFLASH_defconfig b/configs/UCP1020_SPIFLASH_defconfig deleted file mode 100644 index a2d7e6622a..00 --- a/configs/UCP1020_SPIFLASH_defconfig +++ /dev/null @@ -1,60 +0,0 @@ -CONFIG_PPC=y -CONFIG_SYS_TEXT_BASE=0x1100 -CONFIG_MPC85xx=y -CONFIG_TARGET_UCP1020=y -CONFIG_TARGET_UCP1020_SPIFLASH=y -CONFIG_FIT=y -CONFIG_FIT_VERBOSE=y -CONFIG_OF_BOARD_SETUP=y -CONFIG_OF_STDOUT_VIA_ALIAS=y -# CONFIG_MISC_INIT_R is not set -CONFIG_BOARD_EARLY_INIT_F=y -CONFIG_BOARD_EARLY_INIT_R=y -CONFIG_LAST_STAGE_INIT=y -CONFIG_HUSH_PARSER=y -# CONFIG_AUTO_COMPLETE is not set -CONFIG_AUTOBOOT_KEYED=y -CONFIG_AUTOBOOT_PROMPT="Autobooting in %d seconds, press \"\" to stop\n" -CONFIG_AUTOBOOT_STOP_STR="\x1b" -CONFIG_CMD_IMLS=y -CONFIG_CMD_GPIO=y -CONFIG_CMD_I2C=y -CONFIG_CMD_MMC=y -# CONFIG_CMD_NAND is not set -CONFIG_CMD_MMC_SPI=y -CONFIG_CMD_SF=y -CONFIG_CMD_SPI=y -CONFIG_CMD_USB=y -CONFIG_CMD_DHCP=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y -CONFIG_CMD_DATE=y -CONFIG_MP=y -# CONFIG_CMD_HASH is not set -CONFIG_CMD_CRAMFS=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_FAT=y -CONFIG_ENV_IS_IN_SPI_FLASH=y -CONFIG_FSL_ESDHC=y -CONFIG_MTD_NOR_FLASH=y -CONFIG_FLASH_CFI_DRIVER=y -CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y -CONFIG_SYS_FLASH_CFI=y -CONFIG_SPI_FLASH=y -CONFIG_SF_DEFAULT_MODE=0 -CONFIG_SF_DEFAULT_SPEED=1000 -CONFIG_SPI_FLASH_STMICRO=y -CONFIG_SPI_FLASH_SST=y -CONFIG_SPI_FLASH_WINBOND=y -CONFIG_PHY_MARVELL=y -CONFIG_PHY_GIGE=y -CONFIG_E1000=y -CONFIG_MII=y -CONFIG_TSEC_ENET=y -CONFIG_SYS_NS16550=y -CONFIG_SPI=y -CONFIG_FSL_ESPI=y -CONFIG_USB=y -CONFIG_USB_STORAGE=y -CONFIG_FS_CRAMFS=y -CONFIG_OF_LIBFDT=y diff --git a/include/configs/UCP1020.h b/include/configs/UCP1020.h index 268a41c82c..6a01a90425 100644 --- a/include/configs/UCP1020.h +++ b/include/configs/UCP1020.h @@ -438,7 +438,6 @@ #ifdef CONFIG_MMC #define CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_MPC85xx_ESDHC_ADDR -#define CONFIG_MMC_SPI #endif /* Misc Extra Settings */ -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: add comments to phy APIs
On Thu, Jul 11, 2019 at 10:33 AM Alex Marginean wrote: > > Added a comment on the limitations of phy_find_by_mask API when scanning > MDIO buses with multiple PHYs present. Added short descriptions to the > other APIs in phy.h for consistency. > > Signed-off-by: Alex Marginean Thanks for doing this! Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: net: phy: Ignore PHY ID 0 during PHY probing
On 7/9/2019 7:15 PM, Joe Hershberger wrote:
On Tue, Jul 9, 2019 at 10:17 AM Alex Marginean wrote:
On 7/9/2019 4:25 PM, Joe Hershberger wrote:
On Tue, Jul 9, 2019 at 7:53 AM Alex Marginean wrote:
Hi Joe,
On 7/8/2019 8:08 PM, Joe Hershberger wrote:
On Wed, Jul 3, 2019 at 4:01 AM Alex Marginean wrote:
Hi Bin,
On 7/3/2019 10:39 AM, Bin Meng wrote:
Hi Alex,
On Wed, Jul 3, 2019 at 3:09 AM Alex Marginean wrote:
On 7/1/2019 11:15 AM, Bin Meng wrote:
Hi Alex,
On Wed, Jun 19, 2019 at 5:07 PM Alexandru Marginean
wrote:
Current code fails to probe some C45 PHYs that also respond to C22 reads.
This is the case for PHYs like Aquantia AQR112, Marvell 88X2242 (as
previously posted on the u-boot list).
If the PHY ID reads all 0s just ignore it and try the next devad.
Signed-off-by: Alex Marginean
---
drivers/net/phy/phy.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c1c1af9abd..7ccbc4d9da 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -727,6 +727,15 @@ static struct phy_device *create_phy_by_mask(struct
mii_dev *bus,
while (phy_mask) {
int addr = ffs(phy_mask) - 1;
int r = get_phy_id(bus, addr, devad, _id);
+
+ /* If the PHY ID is flat 0 we ignore it. There are C45 PHYs
nits: the multi-line comment block format is wrong
You're right, I'll fix that.
+* that return all 0s for C22 reads (like Aquantia AQR112) and
+* there are C22 PHYs that return all 0s for C45 reads (like
+* Atheros AR8035).
+*/
+ if (phy_id == 0)
+ return NULL;
Should this be "continue"?
In case there are C45 and C22 PHYs mixed on the same bus and they are
all flagged in phy_mask? In general this function shouldn't end up
dealing with multiple PHYs, if it does then it's possible the result
won't the the right one.
If create_phy_by_mask is called from get_phy_device, then we're only
looking for one PHY and if that reads PHY_ID 0 we can just assume we're
not using the correct devad.
create_phy_by_mask can also be called from phy_connect (or some other
place) with phy_mask = 0x. The assumption in that case is that
there is one PHY on the given MDIO bus.
Yes, this is the user scenario that concerns me. But on a shared MDIO
bus, there are multiple PHYs. I remember lots of old Freescale PowerPC
boards did this way. For example, there are multiple eTSEC in the SoC,
and each eTSEC claims to have one MDIO controller, however Freescale
chose to wire all PHYs on a single MDIO bus which usually is eTSEC0
(the first eTSEC).
Virtually all Freescale networking SoCs are like that, each MAC has its
own MDIO controller but those are in fact connected to the SoC internal
PHYs not to the external PHYs on the board. These SoCs have one or two
MDIOs dedicated to the external PHYs. If the SoC supports 10G
interfaces then the SoC typically has two external MDIOs, the intent
being that one is used for C22 and the other for C45 PHYs.
Of course MDIO buses with multiple PHYs have to work. My point is that
one should not end up in this function with a phy_mask with multiple
bits set if the MDIO bus has multiple PHYs connected to it, in that
set-up the caller should know the PHY address up front and set only one
bit in phy_mask.
If there are several PHYs then we're going into a gray area, the result
isn't explicitly defined. We could try to probe the PHY with the
I suspect this function is not being used widely hence not exposing
any known issues?
At least for qoriq and layerscape Freescale SoCs the PHY address is
known up front before calling this function, precisely because the MDIO
bus is shared, but I'm guessing other SoCs do rely on scanning to get
to the PHYs.
Joe, do you have a preference between return and continue when we hit
a PHY_ID == 0? Are you OK with continue?
I wonder if it would be useful to scan all IDs in this function, instead
of returning on 1st hit, just to issue a warning if multiple addresses
flagged in phy_mask return valid PHY IDs. Any thoughts?
Scanning all seems like a bit of an independent question. I think the
return vs continue decision at a higher level is a decision about
whether a phy scan should include or ignore C45 phys, correct? Scan
all seems like it applies to all included phys, C45 being included or
not based on the former decision.
Is there a use case anyone is aware of where C45 phys are expected to
be scanned for?
Assuming there's just one PHY on the bus that's scanned, and it's a C45
PHY, scanning should actually work (that case works with both continue
and return NULL in fact).
create_phy_by_mask is going to read PHY_ID 0 over C22, it can continue
and not find anything else using C22 reads, finally return NULL.
get_phy_device_by_mask will call again with the next devad. Assuming
the PHY replies to
Re: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL
On Wed, Jul 10, 2019 at 04:30:44PM -0500, Andreas Dannenberg wrote:
> On several platforms space is very tight when building for SPL or TPL.
> To claw back a few bytes to be used for code remove the __FILE__ name
> from the BUG() and WARN() type macros. Since those macros still print
> the function name plus a line number this should not really affect
> the ability to backtrace an actual BUG/WARN message to a specific
> piece of code.
>
> Signed-off-by: Andreas Dannenberg
> ---
>
> I was looking for a way to shave off a few bytes from the SPL code size
> (TI AM335x) and looking at the hexdump of the SPL I found well why not
> further reduce some strings down in size... I was already aware of the
> recent compiler optimizations to drop some of the irrelevant path from
> the __FILE__ macro but I wanted to go one step beyond this. Dropping
> all the path from __FILE__ via preprocessor macro can't be easily done
> as others have already found so I decided to drop __FILE__ altogether
> (code below) and was excited about the improvements I got...
Just some quick examples about the savings...
Using buildman "bloat" reporting (-B) I see the SPL .text size for AM335x
to be reduced by 12 bytes. And for AM43xx the size goes down by 52
bytes. The benefit of the proposed change really depends on a) whether a
given platform uses SPL, and b) how many calls to BUG/WARN it has. The
USB drivers in AM335x/AM43xx are really the "heavy hitters" here. I'm
sure I could find additional examples/platforms to highlight savings if
needed.
Anyways I'm not proud of the proposed change but merely wanted to see
with this RFC if there isn't any way to do further optimizations on the
__FILE__ topic that are not overly intrusive specifically as it comes to
SPL.
Best Regards,
Andreas
>
> Then of course using Google I found there was prior art, specifically
> this discussion here:
>
> "[U-Boot] __FILE__ usage and and SPL limits for SRAM"
> https://patchwork.ozlabs.org/patch/746922/
>
>
> So I made this submission to "RFC" to simply re-ignite the subject to
> see if we can somehow find some path to proceed with such a change...
>
> I like about the proposal referenced above that it touches more places
> than what I came up with, however it is missing the TPL/SPL aspect
> which I thought would be a good way to alleviate some of the concerns
> raised (Wolfgang) around not having __FILE__ in the log...
>
> Maybe a combination of the approaches could be workable?
>
> At the end of the day SPL/TPL are intended for very memory-constrained
> environments, so I feel changes like the proposed that don't really
> affect any of the existing functionality are good candidates to
> consider...
>
> Regards,
> Andreas
>
> include/linux/bug.h | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 29f84168a3..36b5fddfae 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -5,9 +5,22 @@
> #include
> #include
> #include
> +#include
> +
> +#if defined(CONFIG_TPL_BUILD) || defined(CONFIG_SPL_BUILD)
> +/*
> + * In case of TPL/SPL use a short format not including __FILE__
> + * to reduce image size
> + */
> +#define BUG_WARN_LOC_FMT "%d@%s()"
> +#define BUG_WARN_LOC_ARGS__LINE__, __func__
> +#else
> +#define BUG_WARN_LOC_FMT "%s:%d/%s()"
> +#define BUG_WARN_LOC_ARGS__FILE__, __LINE__, __func__
> +#endif
>
> #define BUG() do { \
> - printk("BUG at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
> + printk("BUG at " BUG_WARN_LOC_FMT "!\n", BUG_WARN_LOC_ARGS);\
> panic("BUG!"); \
> } while (0)
>
> @@ -16,7 +29,7 @@
> #define WARN_ON(condition) ({
> \
> int __ret_warn_on = !!(condition); \
> if (unlikely(__ret_warn_on))\
> - printk("WARNING at %s:%d/%s()!\n", __FILE__, __LINE__,
> __func__); \
> + printk("WARNING at " BUG_WARN_LOC_FMT "!\n",
> BUG_WARN_LOC_ARGS); \
> unlikely(__ret_warn_on);\
> })
>
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: add comments to phy APIs
Added a comment on the limitations of phy_find_by_mask API when scanning
MDIO buses with multiple PHYs present. Added short descriptions to the
other APIs in phy.h for consistency.
Signed-off-by: Alex Marginean
---
include/phy.h | 80 +++
1 file changed, 80 insertions(+)
diff --git a/include/phy.h b/include/phy.h
index d01435d1aa..f4530faeb9 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -246,15 +246,71 @@ static inline int is_10g_interface(phy_interface_t
interface)
#endif
+/**
+ * phy_init() - Initializes the PHY drivers
+ *
+ * This function registers all available PHY drivers
+ *
+ * @return 0 if OK, -ve on error
+ */
int phy_init(void);
+
+/**
+ * phy_reset() - Resets the specified PHY
+ *
+ * Issues a reset of the PHY and waits for it to complete
+ *
+ * @phydev:PHY to reset
+ * @return 0 if OK, -ve on error
+ */
int phy_reset(struct phy_device *phydev);
+
+/**
+ * phy_find_by_mask() - Searches for a PHY on the specified MDIO bus
+ *
+ * The function checks the PHY addresses flagged in phy_mask and returns a
+ * phy_device pointer if it detects a PHY.
+ * This function should only be called if just one PHY is expected to be
present
+ * in the set of addresses flagged in phy_mask. If multiple PHYs are present,
+ * it is undefined which of these PHYs is returned.
+ *
+ * @bus: MII/MDIO bus to scan
+ * @phy_mask: bitmap of PYH addresses to scan
+ * @interface: type of MAC-PHY interface
+ * @return pointer to phy_device if a PHY is found, or NULL otherwise
+ */
struct phy_device *phy_find_by_mask(struct mii_dev *bus, unsigned phy_mask,
phy_interface_t interface);
+
#ifdef CONFIG_DM_ETH
+
+/**
+ * phy_connect_dev() - Associates the given pair of PHY and Ethernet devices
+ * @phydev:PHY device
+ * @dev: Ethernet device
+ */
void phy_connect_dev(struct phy_device *phydev, struct udevice *dev);
+
+/**
+ * phy_connect() - Creates a PHY device for the Ethernet interface
+ *
+ * Creates a PHY device for the PHY at the given address, if one doesn't exist
+ * already, and associates it with the Ethernet device.
+ * The function may be called with addr <= 0, in this case addr value is
ignored
+ * and the bus is scanned to detect a PHY. Scanning should only be used if
only
+ * one PHY is expected to be present on the MDIO bus, otherwise it is undefined
+ * which PHY is returned.
+ *
+ * @bus: MII/MDIO bus that hosts the PHY
+ * @addr: PHY address on MDIO bus
+ * @dev: Ethernet device to associate to the PHY
+ * @interface: type of MAC-PHY interface
+ * @return pointer to phy_device if a PHY is found, or NULL otherwise
+ */
struct phy_device *phy_connect(struct mii_dev *bus, int addr,
struct udevice *dev,
phy_interface_t interface);
+
static inline ofnode phy_get_ofnode(struct phy_device *phydev)
{
if (ofnode_valid(phydev->node))
@@ -263,10 +319,34 @@ static inline ofnode phy_get_ofnode(struct phy_device
*phydev)
return dev_ofnode(phydev->dev);
}
#else
+
+/**
+ * phy_connect_dev() - Associates the given pair of PHY and Ethernet devices
+ * @phydev:PHY device
+ * @dev: Ethernet device
+ */
void phy_connect_dev(struct phy_device *phydev, struct eth_device *dev);
+
+/**
+ * phy_connect() - Creates a PHY device for the Ethernet interface
+ *
+ * Creates a PHY device for the PHY at the given address, if one doesn't exist
+ * already, and associates it with the Ethernet device.
+ * The function may be called with addr <= 0, in this case addr value is
ignored
+ * and the bus is scanned to detect a PHY. Scanning should only be used if
only
+ * one PHY is expected to be present on the MDIO bus, otherwise it is undefined
+ * which PHY is returned.
+ *
+ * @bus: MII/MDIO bus that hosts the PHY
+ * @addr: PHY address on MDIO bus
+ * @dev: Ethernet device to associate to the PHY
+ * @interface: type of MAC-PHY interface
+ * @return pointer to phy_device if a PHY is found, or NULL otherwise
+ */
struct phy_device *phy_connect(struct mii_dev *bus, int addr,
struct eth_device *dev,
phy_interface_t interface);
+
static inline ofnode phy_get_ofnode(struct phy_device *phydev)
{
return ofnode_null();
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 1/4] video: fsl_dcu_fb: refactor init functions
On Thu, 11 Jul 2019 at 17:26, Igor Opaniuk wrote:
>
> + Oleksandr, Philippe
>
> On Mon, Jun 10, 2019 at 2:47 PM Igor Opaniuk wrote:
> >
> > From: Igor Opaniuk
> >
> > Move dcu-related code to fsl_dcu_probe_common, keep in video_hw_init()
> > only legacy video stack (filling GraphicPanel struct etc.).
> >
> > Add wrappers for all init functions, that will let to provide
> > struct fb_info as an additional param (needed for further moving it from
> > the global scope to driver private data struct in DM converted driver).
> >
> > Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> > ---
> > board/freescale/ls1021aqds/dcu.c | 6 +-
> > board/toradex/colibri_vf/dcu.c | 6 +-
> > drivers/video/fsl_dcu_fb.c | 107 +--
> > include/fsl_dcu_fb.h | 12 +++-
> > 4 files changed, 77 insertions(+), 54 deletions(-)
> >
> > diff --git a/board/freescale/ls1021aqds/dcu.c
> > b/board/freescale/ls1021aqds/dcu.c
> > index 14855ea1d9..c4eac5e302 100644
> > --- a/board/freescale/ls1021aqds/dcu.c
> > +++ b/board/freescale/ls1021aqds/dcu.c
> > @@ -39,7 +39,9 @@ unsigned int dcu_set_pixel_clock(unsigned int pixclock)
> > return div;
> > }
> >
> > -int platform_dcu_init(unsigned int xres, unsigned int yres,
> > +int platform_dcu_init(struct fb_info *fbinfo,
> > + unsigned int xres,
> > + unsigned int yres,
> > const char *port,
> > struct fb_videomode *dcu_fb_videomode)
> > {
> > @@ -85,7 +87,7 @@ int platform_dcu_init(unsigned int xres, unsigned int
> > yres,
> > printf("DCU: Switching to %s monitor @ %ux%u\n", name, xres, yres);
> >
> > pixel_format = 32;
> > - fsl_dcu_init(xres, yres, pixel_format);
> > + fsl_dcu_init(fbinfo, xres, yres, pixel_format);
> >
> > return 0;
> > }
> > diff --git a/board/toradex/colibri_vf/dcu.c b/board/toradex/colibri_vf/dcu.c
> > index c36e90cd22..c688ed79ff 100644
> > --- a/board/toradex/colibri_vf/dcu.c
> > +++ b/board/toradex/colibri_vf/dcu.c
> > @@ -26,11 +26,13 @@ unsigned int dcu_set_pixel_clock(unsigned int pixclock)
> > return div;
> > }
> >
> > -int platform_dcu_init(unsigned int xres, unsigned int yres,
> > +int platform_dcu_init(struct fb_info *fbinfo,
> > + unsigned int xres,
> > + unsigned int yres,
> > const char *port,
> > struct fb_videomode *dcu_fb_videomode)
> > {
> > - fsl_dcu_init(xres, yres, 32);
> > + fsl_dcu_init(fbinfo, xres, yres, 32);
> >
> > return 0;
> > }
> > diff --git a/drivers/video/fsl_dcu_fb.c b/drivers/video/fsl_dcu_fb.c
> > index 9f6e7f83b0..f789ec597d 100644
> > --- a/drivers/video/fsl_dcu_fb.c
> > +++ b/drivers/video/fsl_dcu_fb.c
> > @@ -1,6 +1,7 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> > * Copyright 2014 Freescale Semiconductor, Inc.
> > + * Copyright 2019 Toradex AG
> > *
> > * FSL DCU Framebuffer driver
> > */
> > @@ -240,20 +241,22 @@ static void reset_total_layers(void)
> > }
> > }
> >
> > -static int layer_ctrldesc_init(int index, u32 pixel_format)
> > +static int layer_ctrldesc_init(struct fb_info fbinfo,
> > + int index, u32 pixel_format)
> > {
> > struct dcu_reg *regs = (struct dcu_reg *)CONFIG_SYS_DCU_ADDR;
> > unsigned int bpp = BPP_24_RGB888;
> >
> > dcu_write32(>ctrldescl[index][0],
> > - DCU_CTRLDESCLN_1_HEIGHT(info.var.yres) |
> > - DCU_CTRLDESCLN_1_WIDTH(info.var.xres));
> > + DCU_CTRLDESCLN_1_HEIGHT(fbinfo.var.yres) |
> > + DCU_CTRLDESCLN_1_WIDTH(fbinfo.var.xres));
> >
> > dcu_write32(>ctrldescl[index][1],
> > DCU_CTRLDESCLN_2_POSY(0) |
> > DCU_CTRLDESCLN_2_POSX(0));
> >
> > - dcu_write32(>ctrldescl[index][2], (unsigned
> > int)info.screen_base);
> > + dcu_write32(>ctrldescl[index][2],
> > + (unsigned int)fbinfo.screen_base);
> >
> > switch (pixel_format) {
> > case 16:
> > @@ -294,42 +297,42 @@ static int layer_ctrldesc_init(int index, u32
> > pixel_format)
> > return 0;
> > }
> >
> > -int fsl_dcu_init(unsigned int xres, unsigned int yres,
> > -unsigned int pixel_format)
> > +int fsl_dcu_init(struct fb_info *fbinfo, unsigned int xres,
> > +unsigned int yres, unsigned int pixel_format)
> > {
> > struct dcu_reg *regs = (struct dcu_reg *)CONFIG_SYS_DCU_ADDR;
> > unsigned int div, mode;
> >
> > - info.screen_size =
> > - info.var.xres * info.var.yres * (info.var.bits_per_pixel /
> > 8);
> > + fbinfo->screen_size = fbinfo->var.xres * fbinfo->var.yres *
> > +(fbinfo->var.bits_per_pixel / 8);
> >
> > - if (info.screen_size > CONFIG_VIDEO_FSL_DCU_MAX_FB_SIZE_MB) {
> > -
[U-Boot] [PATCH] video: arm: rpi: Bail out early if querying video information fails
From: Fabian Vogt
When probing we query for the width and hight of the display. If the
firmware does not report any connected display the system will crash.
See https://github.com/raspberrypi/firmware/issues/1157 for details.
Signed-off-by: Fabian Vogt
[mb: update commit message]
Signed-off-by: Matthias Brugger
---
drivers/video/bcm2835.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index bc41090aed..1d2eda084c 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -19,13 +19,15 @@ static int bcm2835_video_probe(struct udevice *dev)
debug("bcm2835: Query resolution...\n");
ret = bcm2835_get_video_size(, );
- if (ret)
+ if (ret || w == 0 || h == 0)
return -EIO;
debug("bcm2835: Setting up display for %d x %d\n", w, h);
ret = bcm2835_set_video_params(, , 32, BCM2835_MBOX_PIXEL_ORDER_RGB,
BCM2835_MBOX_ALPHA_MODE_IGNORED,
_base, _size, );
+ if (ret)
+ return -EIO;
debug("bcm2835: Final resolution is %d x %d\n", w, h);
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] colibri_imx7: boot kernel in secure mode
On Wed, 2019-07-10 at 12:19 +, Philippe Schenker wrote:
> On Wed, 2019-07-03 at 16:50 +0300, Igor Opaniuk wrote:
> > From: Igor Opaniuk
> >
> > NXP downstream kernel uses legacy method to enable other cores,
> > which requires kernel to run in a security mode (althought upstream kernel
> > uses PSCI for this).
> >
> > As we're using NXP kernel in our BSPs, lets enable this by default.
> >
> > Signed-off-by: Igor Opaniuk
>
> Reviewed-by: Philippe Schenker
> Tested-by: Philippe Schenker
Please ignore my Reviewed-by and Tested-by. I Tested it on downstream which
works fine but on mainline only one core comes up by design. I wasn't aware of
that.
Philippe
>
> > ---
> >
> > include/configs/colibri_imx7.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
> > index 40173b18fa..5408577661 100644
> > --- a/include/configs/colibri_imx7.h
> > +++ b/include/configs/colibri_imx7.h
> > @@ -164,7 +164,8 @@
> > "${board}/flash_blk.img && source ${loadaddr}\0" \
> > "setup=setenv setupargs " \
> > "console=tty1 console=${console}" \
> > - ",${baudrate}n8 ${memargs} consoleblank=0\0" \
> > + ",${baudrate}n8 ${memargs} consoleblank=0; " \
> > + "setenv bootm_boot_mode sec\0" \
> > "setupdate=run setsdupdate || run setusbupdate || run setethupdate\0" \
> > "setusbupdate=usb start && setenv interface usb && " \
> > "fatload ${interface} 0:1 ${loadaddr} " \
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 4/4] colibri_vf: enable DM_VIDEO
+ Oleksandr, Philippe On Mon, Jun 10, 2019 at 2:48 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Enable DM_VIDEO for Colibri VF. > > Signed-off-by: Igor Opaniuk > --- > configs/colibri_vf_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig > index 3a267bdbc6..445176aa64 100644 > --- a/configs/colibri_vf_defconfig > +++ b/configs/colibri_vf_defconfig > @@ -88,7 +88,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 > CONFIG_CI_UDC=y > CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_VIDEO_FSL_DCU_FB=y > -CONFIG_VIDEO=y > +CONFIG_DM_VIDEO=y > CONFIG_SYS_CONSOLE_FG_COL=0x00 > CONFIG_OF_LIBFDT_OVERLAY=y > CONFIG_FDT_FIXUP_PARTITIONS=y > -- > 2.17.1 > -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 3/4] ARM: dts: colibri_vf: Add dcu0 node
+ Oleksandr, Philippe
On Mon, Jun 10, 2019 at 2:48 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Add dumb node for NXP Display Control Unit0(DCU), which permits DM_ENABLED
> converted driver to be probed. Currently no display timings are provided
> in this node.
>
> Signed-off-by: Igor Opaniuk
> ---
> arch/arm/dts/vf-colibri-u-boot.dtsi | 4
> arch/arm/dts/vf-colibri.dtsi| 5 +
> arch/arm/dts/vf.dtsi| 6 ++
> 3 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/dts/vf-colibri-u-boot.dtsi
> b/arch/arm/dts/vf-colibri-u-boot.dtsi
> index db86739805..2294ee9551 100644
> --- a/arch/arm/dts/vf-colibri-u-boot.dtsi
> +++ b/arch/arm/dts/vf-colibri-u-boot.dtsi
> @@ -21,3 +21,7 @@
> {
> u-boot,dm-pre-reloc;
> };
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/vf-colibri.dtsi b/arch/arm/dts/vf-colibri.dtsi
> index 91ca4e4ddd..9de4b28e87 100644
> --- a/arch/arm/dts/vf-colibri.dtsi
> +++ b/arch/arm/dts/vf-colibri.dtsi
> @@ -14,6 +14,7 @@
>
> aliases {
> usb0 = /* required for ums */
> + display1 =
> };
>
> reg_usbh_vbus: regulator-usbh-vbus {
> @@ -241,3 +242,7 @@
> pinctrl-0 = <_uart0>;
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
> index 5e3b2c5b9d..5f69d0fd6e 100644
> --- a/arch/arm/dts/vf.dtsi
> +++ b/arch/arm/dts/vf.dtsi
> @@ -145,6 +145,12 @@
> #gpio-cells = <2>;
> };
>
> + dcu0: dcu@40058000 {
> + compatible = "fsl,vf610-dcu";
> + reg = <0x40058000 0x1200>;
> + status = "disabled";
> + };
> +
> ehci0: ehci@40034000 {
> compatible = "fsl,vf610-usb";
> reg = <0x40034000 0x800>;
> --
> 2.17.1
>
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 2/4] video: fsl_dcu_fb: add DM_VIDEO support
+ Oleksandr, Philippe
On Mon, Jun 10, 2019 at 2:47 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Extend the driver to build with DM_VIDEO enabled. DTS files
> must additionally include 'u-boot,dm-pre-reloc' property in
> soc and child nodes to enable driver binding to fsl_dcu_fb device.
>
> Currently display timings aren't obtained from DT.
>
> Signed-off-by: Igor Opaniuk
> ---
> board/toradex/colibri_vf/colibri_vf.c | 4 +-
> drivers/video/Kconfig | 2 +-
> drivers/video/fsl_dcu_fb.c| 112 +-
> 3 files changed, 97 insertions(+), 21 deletions(-)
>
> diff --git a/board/toradex/colibri_vf/colibri_vf.c
> b/board/toradex/colibri_vf/colibri_vf.c
> index 9d63fbf3bd..dad754b31f 100644
> --- a/board/toradex/colibri_vf/colibri_vf.c
> +++ b/board/toradex/colibri_vf/colibri_vf.c
> @@ -430,7 +430,9 @@ int checkboard(void)
> #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
> int ft_board_setup(void *blob, bd_t *bd)
> {
> +#ifndef CONFIG_DM_VIDEO
> int ret = 0;
> +#endif
> #ifdef CONFIG_FDT_FIXUP_PARTITIONS
> static const struct node_info nodes[] = {
> { "fsl,vf610-nfc", MTD_DEV_TYPE_NAND, }, /* NAND flash */
> @@ -440,7 +442,7 @@ int ft_board_setup(void *blob, bd_t *bd)
> puts(" Updating MTD partitions...\n");
> fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
> #endif
> -#ifdef CONFIG_VIDEO_FSL_DCU_FB
> +#if defined(CONFIG_VIDEO_FSL_DCU_FB) && !defined(CONFIG_DM_VIDEO)
> ret = fsl_dcu_fixedfb_setup(blob);
> if (ret)
> return ret;
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index c3781b160d..261fa98517 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -484,7 +484,7 @@ config VIDEO_IVYBRIDGE_IGD
>
> config VIDEO_FSL_DCU_FB
> bool "Enable Freescale Display Control Unit"
> - depends on VIDEO
> + depends on VIDEO || DM_VIDEO
> help
> This enables support for Freescale Display Control Unit (DCU4)
> module found on Freescale Vybrid and QorIQ family of SoCs.
> diff --git a/drivers/video/fsl_dcu_fb.c b/drivers/video/fsl_dcu_fb.c
> index f789ec597d..add64b85b5 100644
> --- a/drivers/video/fsl_dcu_fb.c
> +++ b/drivers/video/fsl_dcu_fb.c
> @@ -8,10 +8,12 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include "videomodes.h"
>
> @@ -219,8 +221,6 @@ struct dcu_reg {
> u32 ctrldescl[DCU_LAYER_MAX_NUM][16];
> };
>
> -static struct fb_info info;
> -
> static void reset_total_layers(void)
> {
> struct dcu_reg *regs = (struct dcu_reg *)CONFIG_SYS_DCU_ADDR;
> @@ -302,7 +302,11 @@ int fsl_dcu_init(struct fb_info *fbinfo, unsigned int
> xres,
> {
> struct dcu_reg *regs = (struct dcu_reg *)CONFIG_SYS_DCU_ADDR;
> unsigned int div, mode;
> -
> +/*
> + * When DM_VIDEO is enabled reservation of framebuffer is done
> + * in advance during bind() call.
> + */
> +#if !CONFIG_IS_ENABLED(DM_VIDEO)
> fbinfo->screen_size = fbinfo->var.xres * fbinfo->var.yres *
> (fbinfo->var.bits_per_pixel / 8);
>
> @@ -310,13 +314,13 @@ int fsl_dcu_init(struct fb_info *fbinfo, unsigned int
> xres,
> fbinfo->screen_size = 0;
> return -ENOMEM;
> }
> -
> /* Reserve framebuffer at the end of memory */
> gd->fb_base = gd->bd->bi_dram[0].start +
> gd->bd->bi_dram[0].size - fbinfo->screen_size;
> fbinfo->screen_base = (char *)gd->fb_base;
>
> memset(fbinfo->screen_base, 0, fbinfo->screen_size);
> +#endif
>
> reset_total_layers();
>
> @@ -429,6 +433,32 @@ int fsl_probe_common(struct fb_info *fbinfo, unsigned
> int *win_x,
> options + 8, fsl_dcu_mode_db);
> }
>
> +#ifndef CONFIG_DM_VIDEO
> +static struct fb_info info;
> +
> +#if defined(CONFIG_OF_BOARD_SETUP)
> +int fsl_dcu_fixedfb_setup(void *blob)
> +{
> + u64 start, size;
> + int ret;
> +
> + start = gd->bd->bi_dram[0].start;
> + size = gd->bd->bi_dram[0].size - info.screen_size;
> +
> + /*
> +* Align size on section size (1 MiB).
> +*/
> + size &= 0xfff0;
> + ret = fdt_fixup_memory_banks(blob, , , 1);
> + if (ret) {
> + eprintf("Cannot setup fb: Error reserving memory\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +#endif
> +
> void *video_hw_init(void)
> {
> static GraphicDevice ctfb;
> @@ -448,25 +478,69 @@ void *video_hw_init(void)
> return
> }
>
> -#if defined(CONFIG_OF_BOARD_SETUP)
> -int fsl_dcu_fixedfb_setup(void *blob)
> +#else /* ifndef CONFIG_DM_VIDEO */
> +
> +static int fsl_dcu_video_probe(struct udevice *dev)
> {
> - u64 start, size;
> - int ret;
> + struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
> +
Re: [U-Boot] [RFC 0/4] Convert fsl_dcu_fb to DM_VIDEO
+ Oleksandr, Philippe On Mon, Jun 10, 2019 at 2:47 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > This series of patches refactors and extends NXP DCU video driver to > be built with DM_VIDEO enabled. DTS files must additionally include > 'u-boot,dm-pre-reloc' property in soc and child nodes to enable driver > binding to fsl_dcu_fb device. > > Current limitations: configuration (display timings etc.) isn't fetched > from the DT node. I plan to add this in the next series. > > Also enables DM_VIDEO by default for Colibri VF. > > > Igor Opaniuk (4): > video: fsl_dcu_fb: refactor init functions > video: fsl_dcu_fb: add DM_VIDEO support > ARM: dts: colibri_vf: Add dcu0 node > colibri_vf: enable DM_VIDEO > > arch/arm/dts/vf-colibri-u-boot.dtsi | 4 + > arch/arm/dts/vf-colibri.dtsi | 5 + > arch/arm/dts/vf.dtsi | 6 + > board/freescale/ls1021aqds/dcu.c | 6 +- > board/toradex/colibri_vf/colibri_vf.c | 4 +- > board/toradex/colibri_vf/dcu.c| 6 +- > configs/colibri_vf_defconfig | 2 +- > drivers/video/Kconfig | 2 +- > drivers/video/fsl_dcu_fb.c| 213 ++ > include/fsl_dcu_fb.h | 12 +- > 10 files changed, 187 insertions(+), 73 deletions(-) > > -- > 2.17.1 > -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 1/4] video: fsl_dcu_fb: refactor init functions
+ Oleksandr, Philippe
On Mon, Jun 10, 2019 at 2:47 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Move dcu-related code to fsl_dcu_probe_common, keep in video_hw_init()
> only legacy video stack (filling GraphicPanel struct etc.).
>
> Add wrappers for all init functions, that will let to provide
> struct fb_info as an additional param (needed for further moving it from
> the global scope to driver private data struct in DM converted driver).
>
> Signed-off-by: Igor Opaniuk
> ---
> board/freescale/ls1021aqds/dcu.c | 6 +-
> board/toradex/colibri_vf/dcu.c | 6 +-
> drivers/video/fsl_dcu_fb.c | 107 +--
> include/fsl_dcu_fb.h | 12 +++-
> 4 files changed, 77 insertions(+), 54 deletions(-)
>
> diff --git a/board/freescale/ls1021aqds/dcu.c
> b/board/freescale/ls1021aqds/dcu.c
> index 14855ea1d9..c4eac5e302 100644
> --- a/board/freescale/ls1021aqds/dcu.c
> +++ b/board/freescale/ls1021aqds/dcu.c
> @@ -39,7 +39,9 @@ unsigned int dcu_set_pixel_clock(unsigned int pixclock)
> return div;
> }
>
> -int platform_dcu_init(unsigned int xres, unsigned int yres,
> +int platform_dcu_init(struct fb_info *fbinfo,
> + unsigned int xres,
> + unsigned int yres,
> const char *port,
> struct fb_videomode *dcu_fb_videomode)
> {
> @@ -85,7 +87,7 @@ int platform_dcu_init(unsigned int xres, unsigned int yres,
> printf("DCU: Switching to %s monitor @ %ux%u\n", name, xres, yres);
>
> pixel_format = 32;
> - fsl_dcu_init(xres, yres, pixel_format);
> + fsl_dcu_init(fbinfo, xres, yres, pixel_format);
>
> return 0;
> }
> diff --git a/board/toradex/colibri_vf/dcu.c b/board/toradex/colibri_vf/dcu.c
> index c36e90cd22..c688ed79ff 100644
> --- a/board/toradex/colibri_vf/dcu.c
> +++ b/board/toradex/colibri_vf/dcu.c
> @@ -26,11 +26,13 @@ unsigned int dcu_set_pixel_clock(unsigned int pixclock)
> return div;
> }
>
> -int platform_dcu_init(unsigned int xres, unsigned int yres,
> +int platform_dcu_init(struct fb_info *fbinfo,
> + unsigned int xres,
> + unsigned int yres,
> const char *port,
> struct fb_videomode *dcu_fb_videomode)
> {
> - fsl_dcu_init(xres, yres, 32);
> + fsl_dcu_init(fbinfo, xres, yres, 32);
>
> return 0;
> }
> diff --git a/drivers/video/fsl_dcu_fb.c b/drivers/video/fsl_dcu_fb.c
> index 9f6e7f83b0..f789ec597d 100644
> --- a/drivers/video/fsl_dcu_fb.c
> +++ b/drivers/video/fsl_dcu_fb.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2019 Toradex AG
> *
> * FSL DCU Framebuffer driver
> */
> @@ -240,20 +241,22 @@ static void reset_total_layers(void)
> }
> }
>
> -static int layer_ctrldesc_init(int index, u32 pixel_format)
> +static int layer_ctrldesc_init(struct fb_info fbinfo,
> + int index, u32 pixel_format)
> {
> struct dcu_reg *regs = (struct dcu_reg *)CONFIG_SYS_DCU_ADDR;
> unsigned int bpp = BPP_24_RGB888;
>
> dcu_write32(>ctrldescl[index][0],
> - DCU_CTRLDESCLN_1_HEIGHT(info.var.yres) |
> - DCU_CTRLDESCLN_1_WIDTH(info.var.xres));
> + DCU_CTRLDESCLN_1_HEIGHT(fbinfo.var.yres) |
> + DCU_CTRLDESCLN_1_WIDTH(fbinfo.var.xres));
>
> dcu_write32(>ctrldescl[index][1],
> DCU_CTRLDESCLN_2_POSY(0) |
> DCU_CTRLDESCLN_2_POSX(0));
>
> - dcu_write32(>ctrldescl[index][2], (unsigned
> int)info.screen_base);
> + dcu_write32(>ctrldescl[index][2],
> + (unsigned int)fbinfo.screen_base);
>
> switch (pixel_format) {
> case 16:
> @@ -294,42 +297,42 @@ static int layer_ctrldesc_init(int index, u32
> pixel_format)
> return 0;
> }
>
> -int fsl_dcu_init(unsigned int xres, unsigned int yres,
> -unsigned int pixel_format)
> +int fsl_dcu_init(struct fb_info *fbinfo, unsigned int xres,
> +unsigned int yres, unsigned int pixel_format)
> {
> struct dcu_reg *regs = (struct dcu_reg *)CONFIG_SYS_DCU_ADDR;
> unsigned int div, mode;
>
> - info.screen_size =
> - info.var.xres * info.var.yres * (info.var.bits_per_pixel / 8);
> + fbinfo->screen_size = fbinfo->var.xres * fbinfo->var.yres *
> +(fbinfo->var.bits_per_pixel / 8);
>
> - if (info.screen_size > CONFIG_VIDEO_FSL_DCU_MAX_FB_SIZE_MB) {
> - info.screen_size = 0;
> + if (fbinfo->screen_size > CONFIG_VIDEO_FSL_DCU_MAX_FB_SIZE_MB) {
> + fbinfo->screen_size = 0;
> return -ENOMEM;
> }
>
> /* Reserve framebuffer at the end of memory */
> gd->fb_base = gd->bd->bi_dram[0].start +
> -
Re: [U-Boot] [GIT PULL] UniPhier SoC updates for v2019.10-rc1
+CC list, just in case.
On Thu, Jul 11, 2019 at 11:19 PM Masahiro Yamada
wrote:
>
> Hi Tom,
>
> Here is a pretty big bulk of changes for -rc1. Please pull!
>
>
>
> The following changes since commit b4944e25744aa42dc23c6912e1cd4ccad270c4e0:
>
> Merge tag 'u-boot-atmel-2019.10-a' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-atmel (2019-07-09
> 08:17:12 -0400)
>
> are available in the Git repository at:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-uniphier.git
> tags/uniphier-v2019.10
>
> for you to fetch changes up to 2ce6b82d340cf1b1e5a43f1b5c8965d0067d5246:
>
> ARM: uniphier: set {kernel, ramdisk, fdt}_addr_r at boot-time
> (2019-07-10 22:42:09 +0900)
>
>
> UniPhier SoC updates for v2019.10
>
> - import DT updates from Linux
>
> - add UniPhier SPI controller driver
>
> - make U-Boot image for 64bit SoCs position independent
>
> - tidy up various init code for next generation SoCs
>
> - misc cleanups
>
>
> Kunihiko Hayashi (1):
> spi: Add SPI controller driver for UniPhier SoCs
>
> Masahiro Yamada (24):
> arm64: add an option to switch visibility of
> CONFIG_SYS_INIT_SP_BSS_OFFSET
> ARM: uniphier_v8_defconfig: make 64bit SoC image position independent
> arm64: dts: uniphier: add reserved-memory for secure memory
> ARM: uniphier: remove empty #ifdef block
> ARM: uniphier: remove unused uniphier_ld11_boot_device_fixup()
> ARM: uniphier: clean up clk/Makefile
> ARM: uniphier: use bool type for have_internal_stm parameter
> ARM: uniphier: include from boot-device.c
> clk: uniphier: add EMMC clock for LD11, LD20, and PXs3
> ARM: uniphier: check DT to determine whether to use support card
> ARM: uniphier: check DT to determine whether to initialize SBC
> ARM: uniphier: make boot_is_swapped() code optional
> ARM: uniphier: detect SD boot mode
> ARM: uniphier: de-couple SG macros into base address and offset
> ARM: uniphier: de-couple SC macros into base address and offset
> ARM: uniphier: detect register base addresses run-time
> ARM: uniphier: make dram_init() independent of SG_MEMCONF
> ARM: uniphier: make dram_init() more generic
> ARM: uniphier: make mem_map run-time configurable
> ARM: uniphier: remove CONFIG_SYS_SDRAM_BASE
> ARM: uniphier: turn uniphier_set_fdt_file() into void function
> ARM: uniphier: set loadaddr at boot-time
> ARM: uniphier: set dram_base environment variable
> ARM: uniphier: set {kernel, ramdisk, fdt}_addr_r at boot-time
>
> Makefile | 4 +-
> arch/arm/Kconfig | 20 +-
> .../cpu/armv8/linux-kernel-image-header-vars.h | 2 +-
> arch/arm/dts/uniphier-ld11.dtsi | 13 +-
> arch/arm/dts/uniphier-ld20.dtsi | 13 +-
> arch/arm/dts/uniphier-pxs3.dtsi | 13 +-
> arch/arm/lib/crt0_64.S | 2 +-
> arch/arm/mach-tegra/Kconfig | 1 +
> arch/arm/mach-tegra/tegra186/Kconfig | 3 -
> arch/arm/mach-tegra/tegra210/Kconfig | 3 -
> arch/arm/mach-uniphier/Makefile | 4 +-
> arch/arm/mach-uniphier/arm32/debug_ll.S | 24 +-
> arch/arm/mach-uniphier/arm64/mem_map.c | 10 +
> arch/arm/mach-uniphier/base-address.c| 67 +++
> arch/arm/mach-uniphier/base-address.h| 18 +
> arch/arm/mach-uniphier/board_late_init.c | 62 ++-
> .../mach-uniphier/boot-device/boot-device-ld11.c | 8 -
> .../mach-uniphier/boot-device/boot-device-pxs3.c | 2 +-
> arch/arm/mach-uniphier/boot-device/boot-device.c | 53 ++-
> arch/arm/mach-uniphier/boot-device/boot-device.h | 1 -
> arch/arm/mach-uniphier/clk/Makefile | 10 +-
> arch/arm/mach-uniphier/clk/clk-dram-ld4.c| 12 +-
> arch/arm/mach-uniphier/clk/clk-dram-pro5.c | 12 +-
> arch/arm/mach-uniphier/clk/clk-dram-pxs2.c | 12 +-
> arch/arm/mach-uniphier/clk/clk-early-ld4.c | 10 +-
> arch/arm/mach-uniphier/clk/clk-ld11.c| 14 +-
> arch/arm/mach-uniphier/clk/clk-ld20.c| 8 +-
> arch/arm/mach-uniphier/clk/clk-ld4.c | 12 +-
> arch/arm/mach-uniphier/clk/clk-pro4.c| 18 +-
> arch/arm/mach-uniphier/clk/clk-pro5.c| 18 +-
> arch/arm/mach-uniphier/clk/clk-pxs2.c| 22 +-
> arch/arm/mach-uniphier/clk/clk-pxs3.c| 8 +-
> arch/arm/mach-uniphier/clk/dpll-ld4.c| 8 +-
> arch/arm/mach-uniphier/clk/dpll-pro4.c | 8 +-
> arch/arm/mach-uniphier/clk/dpll-sld8.c | 12 +-
> arch/arm/mach-uniphier/clk/dpll-tail.c | 4 +-
> arch/arm/mach-uniphier/clk/pll-base-ld20.c | 41 +-
> arch/arm/mach-uniphier/clk/pll-ld11.c
Re: [U-Boot] [PATCH v1] colibri_imx7: boot kernel in secure mode
Hi Tobias, On Wed, Jul 10, 2019 at 3:35 PM Tobias Junghans wrote: > > > > NXP downstream kernel uses legacy method to enable other cores, > > > which requires kernel to run in a security mode (althought upstream > > > kernel > > > uses PSCI for this). > > > > > > As we're using NXP kernel in our BSPs, lets enable this by default. > > > > > > Signed-off-by: Igor Opaniuk > > How does enabling both cores work in upstream kernel? It looks like PSCI does > not work in secure mode using mainline 4.19 LTS kernel. Any hints? Until this > is resolved booting in secure mode per default IMHO is not a good option. > > Best regards > > Tobias > > I'm afraid you're right. Just after a bit of time researching and discussing with Stefan, seems that we need to introduce two different wrappers for booting the mainline kernel and downstream NXP kernel. * NXP kernel has legacy code to enable all cores, which works only when running in secure mode. * Mainline kernel, as you said before, does use PSCI for this, which is provided by U-boot (which adds proper psci nodes to the linux dtb on-fly before transferring control to the linux kernel entry point). When we try to load it in secure mode, it continues running on the same Secure PL1, and communication using SMC calling convention doesn't make sense at this case. -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] incorrect include/config.h causes?
Hello, Would anyone be kind enough to help point me in the right direction for debugging the auto-generated '/include/config.h' file? I've got a missing .h file name in line 8 of /include/config.h and a suspicious looking CONFIG_BOARDDIR I'm attempting to add support for a custom board to u-boot 2017.03 and I find myself in the "if(clueless)" conditional inside the U-Boot Porting Guide of the README :-/ So far, I've worked through README.kconfig (specifically "Tips to add/remove boards" - steps 1-5). My specific symptom is with the auto-generated file 'include/config.h'. After running 'make _defconfig' I receive: # # configuration written to .config # 'make' results in the following output: In file included from ./include/common.h:21:0: include/config.h:8:10: fatal error: configs/.h: No such file or directory #include ^~~~ compilation terminated. #include isn't pointing at a valid header file (which exists as '/configs/.h'). Lines 5 and 8 of /include/config.h look fishy to me: cat -n include/config.h 1 /* Automatically generated - do not edit */ 2 #define CONFIG_IMX_CONFIG board/digi/ccimx6ul/imximage.cfg 3 #define CONFIG_MX6UL1 4 #define CONFIG_DDR_MB 256 5 #define CONFIG_BOARDDIR board/ 6 #include 7 #include 8 #include 9 #include 10 #include 11 #include I had assumed the custom board Kconfig file in the /board folder containing config SYS_BORAD config SYS_CONFIG_NAME would be used to setup #defines like CONFIG_BOARDDIR CONFIG_SYS_BOARD and CONFIG_SYS_CONFIG_NAME Obviously, I've missed something - does anyone have any hints on where to look next? Any docs I still need to read? So far, I've been through README and /docs/REAME.kconfig Thanks! Brian Amos ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Data abort during relocation
Hello all,
I ran into a data abort in uboot during relocation (in relocate_code in
relocate.S), in the "fixloop macro":
ENTRY(relocate_code)
.
/*
* fix .rel.dyn relocations
*/
ldr r2, =__rel_dyn_start /* r2 <- SRC
&__rel_dyn_start */
ldr r3, =__rel_dyn_end /* r3 <- SRC
&__rel_dyn_end */
fixloop:
ldmia r2!, {r0-r1}/*
(r0,r1) <- (SRC location,fixup) */
and r1, r1, #0xff
cmpr1, #23 /*
relative fixup? */
bne fixnext
/* relative fix: increase location by offset */
add r0, r0, r4
ldr r1, [r0] < DataAbort
add r1, r1, r4
str r1, [r0]
fixnext:
cmpr2, r3
blo fixloop
relocate_done:
This happened after I added some trivial code somewhere totally different
and unrelated (somewhere in my board.c file, that only gets called after
relocation anyway). The only thing that I can think of, is that this shifted
some sections in size. Anway,
As far as I can tell, the dynamic relocation code checks if some word in
that region is 23, and if so, will try to use the previous word as address
(and add the relocation offset).
For some reason, r0 was zero somewhere in my case. After adding the
relocation offset (of 0x18722000), the dereferencing is invalid (RAM only
starts at 0x8000.) and causes the abort.
I now patched the code with this, and this fixes the abort for me:
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 475d503..fba30b9 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -98,6 +98,9 @@ fixloop:
and r1, r1, #0xff
cmpr1, #23 /*
relative fixup? */
bne fixnext
+ /* Check that the data is not 0. If so, skip it */
+ cmp r0, #0
+ beq fixnext
/* relative fix: increase location by offset */
add r0, r0, r4
Even though this fixes my issue, I don't understand what exactly this is
trying to relocate in the first place, and what could be the relation with
my seemingly unrelated change. Is this code fully ok? Or is there some edge
case where the data is allowed to be zero?
Does somebody know more about this, so we can check if there is anything
that really needs fixing?
Thanks for any feedback.
Kind regards,
Arnout
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/18] autoboot: Tidy up autoboot code
On Sun, May 05, 2019 at 03:53:24PM -0600, Simon Glass wrote: > This series cleans up autoboot.c a bit to: > > - Convert options to Kconfig > - Use C code instead of C preprocessor where possible > - Add a few comments > > > Simon Glass (18): > main: Use conditional run_preboot_environment_command() > Convert CONFIG_SHOW_BOOT_PROGRESS to Kconfig > Add CONFIG_USE_PREBOOT to boards that use CONFIG_PREBOOT > Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT to Kconfig > autoboot: Use CONFIG_AUTOBOOT_STOP_STR_SHA256 indirectly > autoboot: Drop #ifdef for CONFIG_AUTOBOOT_ENCRYPTION > autoboot: Improve docs for CONFIG_AUTOBOOT_ENCRYPTION > autoboot: Use if() for CONFIG_SILENT_CONSOLE > autoboot: Drop #ifdef CONFIG_AUTOBOOT_KEYED > autoboot: Drop unused CONFIG_MENUPROMPT > autoboot: Rename CONFIG_MENUKEY to CONFIG_AUTOBOOT_MENUKEY > snow: Define CONFIG_AUTOBOOT_MENUKEY > autoboot: Tidy up use of menukey > autoboot: Rename CONFIG_MENU_SHOW to include AUTOBOOT > Convert CONFIG_AUTOBOOT_MENU_SHOW to Kconfig > autoboot: Add comments for menu_show() > autoboot: Move a few more options from #ifdef to if() > autoboot: Adjust the implementation in autoboot_command() Unfortunately this doesn't apply cleanly and needs a bit of work to make apply again, can you please rebase? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] env: Move CONFIG_ENV_UBI_VOLUME_REDUND in Kconfig
Hi, > From: Patrick DELAUNAY > Sent: vendredi 14 juin 2019 13:06 > ; Michal Simek ; York Sun > ; U-Boot STM32 mailman.stormreply.com>; Vipul Kumar ; Patrice > CHOTARD ; Heinrich Schuchardt > ; Alexey Brodkin > Subject: [PATCH 1/2] env: Move CONFIG_ENV_UBI_VOLUME_REDUND in > Kconfig > Importance: High > > Add support of CONFIG_ENV_UBI_VOLUME_REDUND in Kconfig as it is already > done for CONFIG_ENV_UBI_VOLUME. > > As this string is optional, the patch introduces the new boolean option > CONFIG_USE_ENV_UBI_VOLUME_REDUND to activate the feature. > > Only the stm32mp1 board is impacted. > > Signed-off-by: Patrick Delaunay I drop this patch as it is superseded by http://patchwork.ozlabs.org/patch/1100049/ Merged in SHA1 ff4818cc3ec105a5a250188e6914ae233b75aa84 PS: USE_ENV_UBI_VOLUME_REDUND is no more needed in this patchset Patrick > --- > > configs/stm32mp15_basic_defconfig | 2 ++ > configs/stm32mp15_trusted_defconfig | 2 ++ > env/Kconfig | 11 +++ > include/configs/stm32mp1.h | 4 > 4 files changed, 15 insertions(+), 4 deletions(-) > > diff --git a/configs/stm32mp15_basic_defconfig > b/configs/stm32mp15_basic_defconfig > index 4aa184f..f4b42eb 100644 > --- a/configs/stm32mp15_basic_defconfig > +++ b/configs/stm32mp15_basic_defconfig > @@ -52,6 +52,8 @@ CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto" > CONFIG_ENV_EXT4_FILE="/uboot.env" > CONFIG_ENV_UBI_PART="UBI" > CONFIG_ENV_UBI_VOLUME="uboot_config" > +CONFIG_USE_ENV_UBI_VOLUME_REDUND=y > +CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r" > CONFIG_STM32_ADC=y > CONFIG_USB_FUNCTION_FASTBOOT=y > CONFIG_FASTBOOT_BUF_ADDR=0xC000 > diff --git a/configs/stm32mp15_trusted_defconfig > b/configs/stm32mp15_trusted_defconfig > index 66361c8..91b450c 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -44,6 +44,8 @@ CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto" > CONFIG_ENV_EXT4_FILE="/uboot.env" > CONFIG_ENV_UBI_PART="UBI" > CONFIG_ENV_UBI_VOLUME="uboot_config" > +CONFIG_USE_ENV_UBI_VOLUME_REDUND=y > +CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r" > CONFIG_STM32_ADC=y > CONFIG_USB_FUNCTION_FASTBOOT=y > CONFIG_FASTBOOT_BUF_ADDR=0xC000 > diff --git a/env/Kconfig b/env/Kconfig > index 5651685..676d6eb 100644 > --- a/env/Kconfig > +++ b/env/Kconfig > @@ -507,6 +507,17 @@ config ENV_UBI_VOLUME > help > Name of the volume that you want to store the environment in. > > +config USE_ENV_UBI_VOLUME_REDUND > + bool "Enable redunbant UBI volume" > + depends on ENV_IS_IN_UBI > + > +config ENV_UBI_VOLUME_REDUND > + string "UBI volume name, second copy" > + depends on USE_ENV_UBI_VOLUME_REDUND > + help > + Name of the second volume that you want to store the redundant > + environment in. > + > endif > > config USE_DEFAULT_ENV_FILE > diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h index > 1d385e0..0ce2fcb 100644 > --- a/include/configs/stm32mp1.h > +++ b/include/configs/stm32mp1.h > @@ -38,10 +38,6 @@ > */ > #define CONFIG_SYS_LOAD_ADDR STM32_DDR_BASE > > -#if defined(CONFIG_ENV_IS_IN_UBI) > -#define CONFIG_ENV_UBI_VOLUME_REDUND "uboot_config_r" > -#endif > - > #if defined(CONFIG_ENV_IS_IN_SPI_FLASH) > #define CONFIG_ENV_SECT_SIZESZ_256K > #define CONFIG_ENV_OFFSET 0x0028 > -- > 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Export Function Mechanism on i386 Minnowmax board
Hi, I am trying to use the exported function "install_hdlr" on the minnowmax board. I have observed that the first argument is never passed correctly. On closer inspection, I see that the eax register is overwritten by the export function mechanism. What would be the cleanest way to correct this? Regards, Prateek ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
