[U-Boot] Driver probing
Hi all,
I'm working on a driver for our ARM64 SOCs but am having an issue where the
driver never gets probed. I added a bind function and the driver is getting
bound and I have the appropriate entry in the device tree for it, but the probe
function is never called.
This is a pseudo driver in that there is no actual underlying hardware for it
so there is no underlying PCI device. I'm sorry for the poor formatting, but my
employer's email system is unusable.
Any idea on why my driver is not getting probed? The compatible field should
match and the driver is getting bound. The driver is a pseudo serial driver
using shared memory for input.
I have the following entry in the device tree for a memory mapped region:
DTS:
bootcmd: pci-bootcmd@0x03fff000 {
/* remote bootcmd buffer location */
compatible = "marvell,pci-bootcmd";
reg = <0 0x03fff000 0 0x1000>;
};
My driver look like this:
static int octeontx_bootcmd_probe(struct udevice *dev)
{
struct octeontx_bootcmd_data *bc;
struct octeontx_pci_io_buf *buf;
struct octeontx_bootcmd_platdata *plat = dev_get_platdata(dev);
printf("%s(%s)\n", __func__, dev->name);
return 0;
}
static int octeontx_bootcmd_bind(struct udevice *dev)
{
printf("%s(%s)\n", __func__, dev->name);
return 0;
}
static const struct dm_serial_ops octeontx_bootcmd_ops = {
.putc = octeontx_bootcmd_putc,
.pending = octeontx_bootcmd_pending,
.getc = octeontx_bootcmd_getc,
};
static const struct udevice_id octeontx_bootcmd_serial_id[] = {
{ .compatible = "marvell,pci-bootcmd", },
{ },
};
U_BOOT_DRIVER(octeontx_bootcmd) = {
.name = "pci-bootcmd",
.id = UCLASS_SERIAL,
.of_match = of_match_ptr(octeontx_bootcmd_serial_id),
.ofdata_to_platdata = of_match_ptr(octeontx_bootcmd_ofdata_to_platdata),
.platdata_auto_alloc_size = sizeof(struct octeontx_bootcmd_platdata),
.probe = octeontx_bootcmd_probe,
.bind = octeontx_bootcmd_bind,
.ops = &octeontx_bootcmd_ops,
.priv_auto_alloc_size = sizeof(struct octeontx_bootcmd_data),
.flags = DM_FLAG_PRE_RELOC,
};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: rk3399: Fix enabling boot-on regulators
Hi Mark,
On 06/22/2019 04:57 AM, Mark Kettenis wrote:
> The new common rockchip pinctrl driver does not support explicit
> requests for a particular pinctrl function. As a result, the
> board_init() function bails out early before enabling the boot-on
> regulators. Fix this by simply removing the request for pwm0, pwm2
> and pwm3. The generic DM code already does the necessary
> configuration if necessary.
>
> Reported-by: Levin Du
> Signed-of-by: Mark Kettenis
Reveiwed-by: Kever Yang
Thanks,
- Kever
> ---
> Without this patch the boot-on regulators are not enabled and the
> my firefly-rk3399 doesn't run OpenBSD stable without it. Levin Du
> reported similar problems with Linux. I'd say this is a critical
> fix that should make the 2019.07 release.
>
> This patch deliberately does not touch the code in spl_boot_init()
> as Jagan Teki just posted a patchset that touches those bits.
>
> board/rockchip/evb_rk3399/evb-rk3399.c | 32 +-
> 1 file changed, 1 insertion(+), 31 deletions(-)
>
> diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c
> b/board/rockchip/evb_rk3399/evb-rk3399.c
> index bf2ad98c47..8c20bd6e11 100644
> --- a/board/rockchip/evb_rk3399/evb-rk3399.c
> +++ b/board/rockchip/evb_rk3399/evb-rk3399.c
> @@ -13,39 +13,9 @@
>
> int board_init(void)
> {
> - struct udevice *pinctrl, *regulator;
> + struct udevice *regulator;
> int ret;
>
> - /*
> - * The PWM do not have decicated interrupt number in dts and can
> - * not get periph_id by pinctrl framework, so let's init them here.
> - * The PWM2 and PWM3 are for pwm regulater.
> - */
> - ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
> - if (ret) {
> - debug("%s: Cannot find pinctrl device\n", __func__);
> - goto out;
> - }
> -
> - /* Enable pwm0 for panel backlight */
> - ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM0);
> - if (ret) {
> - debug("%s PWM0 pinctrl init fail! (ret=%d)\n", __func__, ret);
> - goto out;
> - }
> -
> - ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM2);
> - if (ret) {
> - debug("%s PWM2 pinctrl init fail!\n", __func__);
> - goto out;
> - }
> -
> - ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM3);
> - if (ret) {
> - debug("%s PWM3 pinctrl init fail!\n", __func__);
> - goto out;
> - }
> -
> ret = regulators_enable_boot_on(false);
> if (ret)
> debug("%s: Cannot enable boot on regulator\n", __func__);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3399: rockpro64: Provide init voltage
On 06/22/2019 05:16 AM, Mark Kettenis wrote:
> Add missing regulator-init-microvolt property to vdd_log regulator.
>
> Signed-off-by: Mark Kettenis
Reveiwed-by: Kever Yang
Thanks,
- Kever
> ---
> Without this property the pwm regulator driver prints a warning and
> the OpenBSD kernel crashes shortly after spinning up the big cores.
>
> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index dbfa4ba9f8..f7f26d584f 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -5,3 +5,7 @@
>
> #include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +&vdd_log {
> + regulator-init-microvolt = <95>;
> +};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/8] board: rk3399: Drop explicit uart enablement in spl_board_init
Hi Jagan,
On 06/21/2019 02:54 AM, Jagan Teki wrote:
> preloader_console_init is used for printing SPL boot banner that
> usually called from spl_board_init.
>
> The current spl_board_init in evb and rock960 is enabling explicit
> pinctrl, debug uart prior to calling preloader_console_init which
> eventually not required since board_init_f is already enabled
> debug uart.
>
> So, drop those explicit enablement calls from spl_board_init of
> evb, rock960.
>
> Tested this by enabling CONFIG_SPL_BOARD_INIT and adding
> u-boot,dm-pre-reloc property for uart node.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> board/rockchip/evb_rk3399/evb-rk3399.c | 23 +--
> board/vamrs/rock960_rk3399/rock960-rk3399.c | 25 +
> 2 files changed, 2 insertions(+), 46 deletions(-)
>
> diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c
> b/board/rockchip/evb_rk3399/evb-rk3399.c
> index bf2ad98c47..769b5d146f 100644
> --- a/board/rockchip/evb_rk3399/evb-rk3399.c
> +++ b/board/rockchip/evb_rk3399/evb-rk3399.c
> @@ -6,7 +6,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -68,27 +67,7 @@ out:
>
> void spl_board_init(void)
> {
> - struct udevice *pinctrl;
> - int ret;
> -
> - ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
> - if (ret) {
> - debug("%s: Cannot find pinctrl device\n", __func__);
> - goto err;
> - }
> -
> - /* Enable debug UART */
> - ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_UART_DBG);
> - if (ret) {
> - debug("%s: Failed to set up console UART\n", __func__);
> - goto err;
> - }
> -
> preloader_console_init();
> - return;
> -err:
> - printf("%s: Error %d\n", __func__, ret);
>
> - /* No way to report error here */
> - hang();
> + return;
> }
> diff --git a/board/vamrs/rock960_rk3399/rock960-rk3399.c
> b/board/vamrs/rock960_rk3399/rock960-rk3399.c
> index 0f5ef3a09a..018e4b55b8 100644
> --- a/board/vamrs/rock960_rk3399/rock960-rk3399.c
> +++ b/board/vamrs/rock960_rk3399/rock960-rk3399.c
> @@ -5,9 +5,6 @@
>
> #include
> #include
> -#include
> -#include
> -#include
> #include
> #include
>
> @@ -24,27 +21,7 @@ int board_init(void)
>
> void spl_board_init(void)
> {
> - struct udevice *pinctrl;
> - int ret;
> -
> - ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
> - if (ret) {
> - debug("%s: Cannot find pinctrl device\n", __func__);
> - goto err;
> - }
> -
> - /* Enable debug UART */
> - ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_UART_DBG);
> - if (ret) {
> - debug("%s: Failed to set up console UART\n", __func__);
> - goto err;
> - }
> -
> preloader_console_init();
> - return;
> -err:
> - printf("%s: Error %d\n", __func__, ret);
>
> - /* No way to report error here */
> - hang();
> + return;
> }
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] rockchip: rk3399: Support common spl_board_init
Hi Jagan,
On 06/21/2019 02:55 AM, Jagan Teki wrote:
> Support common spl_board_init by moving code from puma
> board file into, common rk3399-board-spl.c.
>
> Part of the code has sysreset-gpio, regulators_enable_boot_on
> but right now only puma board is using this with relevant
> config options rest remains common for all targets.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/mach-rockchip/rk3399-board-spl.c | 63 +++
> board/rockchip/evb_rk3399/evb-rk3399.c| 8 ---
> .../puma_rk3399/puma-rk3399.c | 58 -
> board/vamrs/rock960_rk3399/rock960-rk3399.c | 8 ---
> 4 files changed, 63 insertions(+), 74 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3399-board-spl.c
> b/arch/arm/mach-rockchip/rk3399-board-spl.c
> index 800ca80022..65c98b697d 100644
> --- a/arch/arm/mach-rockchip/rk3399-board-spl.c
> +++ b/arch/arm/mach-rockchip/rk3399-board-spl.c
> @@ -11,13 +11,16 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> void board_return_to_bootrom(void)
> @@ -202,6 +205,66 @@ void board_init_f(ulong dummy)
> }
> }
>
> +#if defined(SPL_GPIO_SUPPORT)
> +static void rk3399_force_power_on_reset(void)
> +{
> + ofnode node;
> + struct gpio_desc sysreset_gpio;
> +
> + debug("%s: trying to force a power-on reset\n", __func__);
> +
> + node = ofnode_path("/config");
> + if (!ofnode_valid(node)) {
> + debug("%s: no /config node?\n", __func__);
> + return;
> + }
> +
> + if (gpio_request_by_name_nodev(node, "sysreset-gpio", 0,
> +&sysreset_gpio, GPIOD_IS_OUT)) {
> + debug("%s: could not find a /config/sysreset-gpio\n", __func__);
> + return;
> + }
> +
> + dm_gpio_set_value(&sysreset_gpio, 1);
> +}
> +#endif
> +
> +void spl_board_init(void)
> +{
> +#if defined(SPL_GPIO_SUPPORT)
> + struct rk3399_cru *cru = rockchip_get_cru();
> +
> + /*
> + * The RK3399 resets only 'almost all logic' (see also in the TRM
> + * "3.9.4 Global software reset"), when issuing a software reset.
> + * This may cause issues during boot-up for some configurations of
> + * the application software stack.
> + *
> + * To work around this, we test whether the last reset reason was
> + * a power-on reset and (if not) issue an overtemp-reset to reset
> + * the entire module.
> + *
> + * While this was previously fixed by modifying the various places
> + * that could generate a software reset (e.g. U-Boot's sysreset
> + * driver, the ATF or Linux), we now have it here to ensure that
> + * we no longer have to track this through the various components.
> + */
> + if (cru->glb_rst_st != 0)
> + rk3399_force_power_on_reset();
> +#endif
> +
> +#if defined(SPL_DM_REGULATOR)
> + /*
> + * Turning the eMMC and SPI back on (if disabled via the Qseven
> + * BIOS_ENABLE) signal is done through a always-on regulator).
> + */
> + if (regulators_enable_boot_on(false))
> + debug("%s: Cannot enable boot on regulator\n", __func__);
> +#endif
> +
> + preloader_console_init();
> +}
> +
> #ifdef CONFIG_SPL_LOAD_FIT
> int board_fit_config_name_match(const char *name)
> {
> diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c
> b/board/rockchip/evb_rk3399/evb-rk3399.c
> index 769b5d146f..c600553ff6 100644
> --- a/board/rockchip/evb_rk3399/evb-rk3399.c
> +++ b/board/rockchip/evb_rk3399/evb-rk3399.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
>
> int board_init(void)
> {
> @@ -64,10 +63,3 @@ int board_init(void)
> out:
> return 0;
> }
> -
> -void spl_board_init(void)
> -{
> - preloader_console_init();
> -
> - return;
> -}
> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> index c6b509c109..251cd2d566 100644
> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> @@ -13,10 +13,8 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -38,62 +36,6 @@ int board_init(void)
> return 0;
> }
>
> -static void rk3399_force_power_on_reset(void)
> -{
> - ofnode node;
> - struct gpio_desc sysreset_gpio;
> -
> - debug("%s: trying to force a power-on reset\n", __func__);
> -
> - node = ofnode_path("/config");
> - if (!ofnode_valid(node)) {
> - debug("%s: no /config node?\n", __func__);
> - return;
> - }
> -
> - if (gpio_request_by_name_nodev(node, "sysreset-gpio", 0,
> -&sysreset_gpio, GPIOD_IS_OUT)) {
> - debug("%s:
Re: [U-Boot] [PATCH v2 3/8] rockchip: rk3399: spl: Mark printascii into debug
Hi Jagan,
On 06/21/2019 02:55 AM, Jagan Teki wrote:
> Now, we have spl_board_init with preloader_console_init that
> indeed show SPL banner.
>
> So mark the 'U-Boot SPL board init' print into debug.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/mach-rockchip/rk3399-board-spl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3399-board-spl.c
> b/arch/arm/mach-rockchip/rk3399-board-spl.c
> index 65c98b697d..890d80025f 100644
> --- a/arch/arm/mach-rockchip/rk3399-board-spl.c
> +++ b/arch/arm/mach-rockchip/rk3399-board-spl.c
> @@ -164,7 +164,7 @@ void board_init_f(ulong dummy)
>* printhex8(0x1234);
>* printascii("string");
>*/
> - printascii("U-Boot SPL board init\n");
> + debug("U-Boot SPL board init\n");
> #endif
>
> ret = spl_early_init();
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/8] rockchip: rk3399: Move u-boot, dm-pre-reloc of uart0, uart2
Hi Jagan,
On 06/21/2019 02:55 AM, Jagan Teki wrote:
> u-boot,dm-pre-reloc for uart0, uart2 indeed u-boot specific
> properties. Move them into rk3399-u-boot.dtsi so the boards
> which enabled these node will available during SPL.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-gru.dtsi| 1 -
> arch/arm/dts/rk3399-puma.dtsi | 1 -
> arch/arm/dts/rk3399-u-boot.dtsi | 8
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
> index ca0fc391b2..0e2e047180 100644
> --- a/arch/arm/dts/rk3399-gru.dtsi
> +++ b/arch/arm/dts/rk3399-gru.dtsi
> @@ -629,7 +629,6 @@ ap_i2c_audio: &i2c8 {
>
> &uart2 {
> status = "okay";
> - u-boot,dm-pre-reloc;
> };
>
> &usb_host0_ohci {
> diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> index 897e0bda85..74368da550 100644
> --- a/arch/arm/dts/rk3399-puma.dtsi
> +++ b/arch/arm/dts/rk3399-puma.dtsi
> @@ -639,7 +639,6 @@
> };
>
> &uart0 {
> - u-boot,dm-pre-reloc;
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_xfer &uart0_cts>;
> status = "okay";
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 0786c1193a..fcfce9ae02 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -10,3 +10,11 @@
> &spi1 {
> u-boot,dm-pre-reloc;
> };
> +
> +&uart0 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart2 {
> + u-boot,dm-pre-reloc;
> +};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] rockchip: rk3399: Enable SPL_BOARD_INIT
Hi Jagan, On 06/21/2019 02:55 AM, Jagan Teki wrote: > Enable SPL_BOARD_INIT globally to rk3399, this would > help to print the SPL banner during bootup. > > Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever > --- > arch/arm/mach-rockchip/Kconfig | 1 + > configs/puma-rk3399_defconfig | 1 - > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index c05e3c3f48..ce039022df 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -158,6 +158,7 @@ config ROCKCHIP_RK3399 > select SPL > select SPL_ATF > select SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF > + select SPL_BOARD_INIT if SPL > select SPL_LOAD_FIT > select SPL_CLK if SPL > select SPL_PINCTRL if SPL > diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig > index ebc78fb216..5cb2273a15 100644 > --- a/configs/puma-rk3399_defconfig > +++ b/configs/puma-rk3399_defconfig > @@ -21,7 +21,6 @@ CONFIG_MISC_INIT_R=y > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > CONFIG_SPL_TEXT_BASE=0xff8c2000 > -CONFIG_SPL_BOARD_INIT=y > # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set > # CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set > CONFIG_SPL_STACK_R=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/8] rockchip: rk3399: tpl: Add spl_board_init
Hi Jagan,
On 06/21/2019 02:55 AM, Jagan Teki wrote:
> Add spl_board_init for TPL, that have TPL banner will help
> to print tpl boot prints.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/mach-rockchip/rk3399-board-tpl.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3399-board-tpl.c
> b/arch/arm/mach-rockchip/rk3399-board-tpl.c
> index 86d3ffe97c..72d0dd914e 100644
> --- a/arch/arm/mach-rockchip/rk3399-board-tpl.c
> +++ b/arch/arm/mach-rockchip/rk3399-board-tpl.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -73,6 +74,12 @@ u32 spl_boot_device(void)
> return BOOT_DEVICE_BOOTROM;
> }
>
> +void spl_board_init(void)
> +{
> + puts("\nU-Boot TPL " PLAIN_VERSION " (" U_BOOT_DATE " - "
> + U_BOOT_TIME " " U_BOOT_TZ ")\n");
> +}
> +
> #ifdef CONFIG_SPL_LOAD_FIT
> int board_fit_config_name_match(const char *name)
> {
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/8] rockchip: rk3399: tpl: Mark printascii into debug
Hi Jagan,
On 06/21/2019 02:55 AM, Jagan Teki wrote:
> Now, we have spl_board_init which has TPL banner prints.
>
> So mark the 'U-Boot TPL board init' print into debug.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/mach-rockchip/rk3399-board-tpl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3399-board-tpl.c
> b/arch/arm/mach-rockchip/rk3399-board-tpl.c
> index 72d0dd914e..4a301249b4 100644
> --- a/arch/arm/mach-rockchip/rk3399-board-tpl.c
> +++ b/arch/arm/mach-rockchip/rk3399-board-tpl.c
> @@ -47,7 +47,7 @@ void board_init_f(ulong dummy)
>* printhex8(0x1234);
>* printascii("string");
>*/
> - printascii("U-Boot TPL board init\n");
> + debug("U-Boot TPL board init\n");
> #endif
> ret = spl_early_init();
> if (ret) {
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/8] rockchip: rk3399: Enable TPL_BOARD_INIT
Hi Jagan, On 06/21/2019 02:55 AM, Jagan Teki wrote: > Enable TPL_BOARD_INIT, this would help us to show > TPL boot prints. > > Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever > --- > arch/arm/mach-rockchip/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index ce039022df..1d483be8b9 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -184,6 +184,7 @@ config ROCKCHIP_RK3399 > imply TPL_LIBCOMMON_SUPPORT > imply TPL_LIBGENERIC_SUPPORT > imply TPL_SYS_MALLOC_SIMPLE > + imply TPL_BOARD_INIT > imply TPL_BOOTROM_SUPPORT > imply TPL_DRIVERS_MISC_SUPPORT > imply TPL_OF_CONTROL ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] watchdog: tangier: Replace unused constant with a comment
On Fri, Jun 21, 2019 at 6:28 PM Andy Shevchenko wrote: > > The default timeout value had been left in order to leave some traces > about default setup of watchdog done by firmware. > > For better understanding and compiler burden, replace it with a comment. > > Suggested-by: Stefan Roese > Signed-off-by: Andy Shevchenko > --- > drivers/watchdog/tangier_wdt.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] x86: Revert "Don't set up MTRRs in SPL"
On Wed, Jun 19, 2019 at 12:12 AM Bin Meng wrote: > > On Wed, Jun 19, 2019 at 12:06 AM Andy Shevchenko > wrote: > > > > This breaks Intel Edison to work. It gets laggish and unable to boot kernel. > > > > Reverts commit 665cb18ea64aabbeb03d27a4c92ddec1baccb87a for now > > till better solution will be proposed. > > > > Signed-off-by: Andy Shevchenko > > --- > > arch/x86/lib/init_helpers.c | 5 + > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > Acked-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 v3 1/2] watchdog: tangier: Replace unused constant with a comment
On Sat, Jun 22, 2019 at 10:23 PM Bin Meng wrote: > > On Fri, Jun 21, 2019 at 6:28 PM Andy Shevchenko > wrote: > > > > The default timeout value had been left in order to leave some traces > > about default setup of watchdog done by firmware. > > > > For better understanding and compiler burden, replace it with a comment. > > > > Suggested-by: Stefan Roese > > Signed-off-by: Andy Shevchenko > > --- > > drivers/watchdog/tangier_wdt.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > 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 v3 2/2] watchdog: tangier: Convert to use WDT class
On Fri, Jun 21, 2019 at 6:28 PM Andy Shevchenko wrote: > > Convert legacy driver to use watchdog class. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Stefan Roese > --- > arch/x86/cpu/tangier/Kconfig | 1 - > arch/x86/dts/edison.dts| 4 ++ > configs/edison_defconfig | 2 + > drivers/watchdog/Kconfig | 17 > drivers/watchdog/Makefile | 2 +- > drivers/watchdog/tangier_wdt.c | 73 +- > 6 files changed, 60 insertions(+), 39 deletions(-) > 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] rockchip: dts: rk3399: rockpro64: Provide init voltage
On Sat, Jun 22, 2019 at 2:46 AM Mark Kettenis wrote:
>
> Add missing regulator-init-microvolt property to vdd_log regulator.
>
> Signed-off-by: Mark Kettenis
> ---
> Without this property the pwm regulator driver prints a warning and
> the OpenBSD kernel crashes shortly after spinning up the big cores.
>
> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index dbfa4ba9f8..f7f26d584f 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -5,3 +5,7 @@
>
> #include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +&vdd_log {
> + regulator-init-microvolt = <95>;
> +};
This seems to be issue on whole? how does Linux work? if it required
in Linux better make a change there and sync here.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] qemu-x86: Use config_distro_bootcmd
Hi Joshua, On Fri, Jun 21, 2019 at 11:17 PM Joshua Watt wrote: > > Converts qemu x86 machines to boot using distro_config. The intent is to > allow u-boot in qemu to be maximally compatible with many boot methods > without having to change the config. Currently, u-boot will only boot in > a very limited set of circumstances where there is a /boot/vmlinuz on > scsi 0:3 with no ramdisk. > > If distro_bootcmd fails, u-boot will fall back to the original method. > > Signed-off-by: Joshua Watt > --- > include/configs/qemu-x86.h | 30 ++ Could you please enable > 1 file changed, 30 insertions(+) > > diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h > index 64e7a60b8a..d9c96e295d 100644 > --- a/include/configs/qemu-x86.h > +++ b/include/configs/qemu-x86.h > @@ -10,8 +10,38 @@ > #ifndef __CONFIG_H > #define __CONFIG_H > > +#include > + > +#define CONFIG_BOOTCOMMAND \ > + "run distro_bootcmd; " \ > + "ext2load scsi 0:3 0100 /boot/vmlinuz; " \ > + "zboot 0100" This should be in the board defconfig files. I would like to only keep the "run distro_bootcmd" command. > + > +#define BOOT_TARGET_DEVICES(func) \ > + func(USB, usb, 0) \ > + func(SCSI, scsi, 0) \ > + func(VIRTIO, virtio, 0) \ > + func(IDE, ide, 0) \ > + func(DHCP, dhcp, na) > + > +#include > #include > > +#undef CONFIG_ENV_SIZE > +#define CONFIG_ENV_SIZESZ_256K > + > +#define CONFIG_PREBOOT "pci enum" > + > +#undef CONFIG_EXTRA_ENV_SETTINGS > +#define CONFIG_EXTRA_ENV_SETTINGS \ > + CONFIG_STD_DEVICES_SETTINGS \ > + "scriptaddr=0x800\0" \ QEMU default memory is 128MiB, so I would put this to somewhere that does not break the default one, like 0x700? > + "kernel_addr_r=0x100\0" \ > + "ramdisk_addr_r=0x400\0" \ > + "consoledev=ttyS0\0" \ > + CONFIG_OTHBOOTARGS \ > + BOOTENV > + > #define CONFIG_SYS_MONITOR_LEN (1 << 20) > > #define CONFIG_STD_DEVICES_SETTINGS"stdin=serial,i8042-kbd\0" \ > -- CONFIG_DISTRO_DEFAULTS should also be turned on in the board defconfig files. Could you please update the README.x86 about testing distro boot on QEMU? Thanks! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] qemu-x86: Use config_distro_bootcmd
On Sat, Jun 22, 2019 at 10:51 PM Bin Meng wrote: > > Hi Joshua, > > On Fri, Jun 21, 2019 at 11:17 PM Joshua Watt wrote: > > > > Converts qemu x86 machines to boot using distro_config. The intent is to > > allow u-boot in qemu to be maximally compatible with many boot methods > > without having to change the config. Currently, u-boot will only boot in > > a very limited set of circumstances where there is a /boot/vmlinuz on > > scsi 0:3 with no ramdisk. > > > > If distro_bootcmd fails, u-boot will fall back to the original method. > > > > Signed-off-by: Joshua Watt > > --- > > include/configs/qemu-x86.h | 30 ++ > > Could you please enable Oops, I wanted to say: enable CONFIG_DISTRO_DEFAULTS in the board defconfig files. > > > 1 file changed, 30 insertions(+) > > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.07-rc4 released
Hi Tom, On Tue, 11 Jun 2019 at 02:33, Tom Rini wrote: > > Hey all, > > It's release day and here is v2019.07-rc4. At this point, I know we > have some regression fixes for i.MX that are coming, and I'm expecting a > fix to the build time failure for tinker-rk3288. > > To repeat myself about DM migration deadlines, first, let me say again, > that DM is not required for SPL. This comes up enough that I want to > say it again here. Next, if there is active progress on converting > things, we'll keep from pulling the code out. This is why for example, > we haven't yet pulled out a lot of deprecated SPI code. Some of it is > still in progress on being converted, so I need to update the series I > posted after the last -rc to remove still less drivers. > > In terms of a changelog, > git log --merges v2019.07-rc3..v2019.07-rc4 > continues to improve in quality. If you're sending me a PR, please > include a few lines or words in summary and I'll be sure to put it into > the merge commit. > > As I mentioned with -rc3, with this cycle is coming closer to an end, > it's time to decide if we're going to keep this 3 month cycle or go back > to 2 months. After the last release while I did get some feedback, the > overall balance is still in the 3 month bucket. I vote for 2 months. I find the current release disappears into a black hole for a about a month, and patches sit on the list for what seems like eternity. I have the option of doing a -next branch but it seems that very few do this. I'd like to better understand the benefits of the 3-month timeline. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-x86
Hi Tom, This includes the following changes to U-Boot x86 for v2019.07: - boot failure fix for Intel edison - tangier wdt conversion to driver model The following changes since commit 226a35ef0ef310d8fffa3e6283ee3aab9dab26aa: Merge branch '2019-06-20-master-imports' (2019-06-20 21:52:31 -0400) are available in the git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-x86 for you to fetch changes up to c974a3d1550557f246c98480083651c0a502e7e7: watchdog: tangier: Convert to use WDT class (2019-06-22 22:27:13 +0800) Andy Shevchenko (3): x86: Revert "Don't set up MTRRs in SPL" watchdog: tangier: Replace unused constant with a comment watchdog: tangier: Convert to use WDT class arch/x86/cpu/tangier/Kconfig | 1 - arch/x86/dts/edison.dts| 4 arch/x86/lib/init_helpers.c| 5 + configs/edison_defconfig | 2 ++ drivers/watchdog/Kconfig | 17 - drivers/watchdog/Makefile | 2 +- drivers/watchdog/tangier_wdt.c | 78 ++ 7 files changed, 66 insertions(+), 43 deletions(-) Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Custodians] [ANN] U-Boot v2019.07-rc4 released
On 6/22/19 4:55 PM, Simon Glass wrote: > Hi Tom, > > On Tue, 11 Jun 2019 at 02:33, Tom Rini wrote: >> >> Hey all, >> >> It's release day and here is v2019.07-rc4. At this point, I know we >> have some regression fixes for i.MX that are coming, and I'm expecting a >> fix to the build time failure for tinker-rk3288. >> >> To repeat myself about DM migration deadlines, first, let me say again, >> that DM is not required for SPL. This comes up enough that I want to >> say it again here. Next, if there is active progress on converting >> things, we'll keep from pulling the code out. This is why for example, >> we haven't yet pulled out a lot of deprecated SPI code. Some of it is >> still in progress on being converted, so I need to update the series I >> posted after the last -rc to remove still less drivers. >> >> In terms of a changelog, >> git log --merges v2019.07-rc3..v2019.07-rc4 >> continues to improve in quality. If you're sending me a PR, please >> include a few lines or words in summary and I'll be sure to put it into >> the merge commit. >> >> As I mentioned with -rc3, with this cycle is coming closer to an end, >> it's time to decide if we're going to keep this 3 month cycle or go back >> to 2 months. After the last release while I did get some feedback, the >> overall balance is still in the 3 month bucket. > > I vote for 2 months. I find the current release disappears into a > black hole for a about a month, and patches sit on the list for what > seems like eternity. I have the option of doing a -next branch but it > seems that very few do this. > > I'd like to better understand the benefits of the 3-month timeline. Stability, with the 2 months cycle, there was no time to stabilize the release and fix bugs, everyone was just cannonfodding patches upstream all the time. The result was always a release which wasn't quite well done, had rough edges, unfixed bugs and it wasn't something which you could deploy. Now we have 1 month window where we only accept bugfixes and where things slow down. This removes some stress from the maintainers too. And that lets us take a step back and think about the bigger project questions, rather than just dealing with the onslaught of patches. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Simon, Am 22.06.19 um 16:55 schrieb Simon Glass: > I'd like to better understand the benefits of the 3-month timeline. It takes time to learn about a release, package and build it, test it on various hardware, investigate and report errors, wait for feedback and fixes, rinse and repeat with the next -rc. Many people don't do this as their main job. If we shorten the release cycle, newer boards will get out faster (which is good) but the overall quality of boards not actively worked on (because they were working good enough before) will decay, which is bad. The only way to counteract that would be to automatically test on real hardware rather than just building, and doing that for all these masses of boards seems unrealistic. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3399: rockpro64: Provide init voltage
> From: Jagan Teki
> Date: Sat, 22 Jun 2019 20:17:13 +0530
>
> On Sat, Jun 22, 2019 at 2:46 AM Mark Kettenis wrote:
> >
> > Add missing regulator-init-microvolt property to vdd_log regulator.
> >
> > Signed-off-by: Mark Kettenis
> > ---
> > Without this property the pwm regulator driver prints a warning and
> > the OpenBSD kernel crashes shortly after spinning up the big cores.
> >
> > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > index dbfa4ba9f8..f7f26d584f 100644
> > --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > @@ -5,3 +5,7 @@
> >
> > #include "rk3399-u-boot.dtsi"
> > #include "rk3399-sdram-lpddr4-100.dtsi"
> > +
> > +&vdd_log {
> > + regulator-init-microvolt = <95>;
> > +};
>
> This seems to be issue on whole? how does Linux work? if it required
> in Linux better make a change there and sync here.
It needs the fix to actually turn on the boot-on regulators as well.
But yes, with this property in the device tree, U-Boot enables the
regulator with the appropriate voltage and the crash I'm seeing is gone.
I deliberately made this change in the rk3399-rockpro64-u-boot.dtsi
file since the "regulator-init-microvolt" property is *not* defined by
the Linux devicetree bindings. So I expect that a patch to change
this in the Linux device tree would be rejected.
Note that this regulator has a "regulator-boot-on" property. So Linux
doesn't need to know the initial setting of this regulator as the
bootloader/firmware is supposed to set it up.
I don't know if folks running Linux are experiencing problems as wll;
I don't run Linux on my boards ;). I suspect very few people are
actually using mainline U-Boot on their boards. But it is also
possible that the Linux kernel does enable this regulator when it
boots, since it sees that it hasn't been enabled. It does have some
fallback code to fix that up in case the bootloader/firmware didn't do
things properly. But what voltage would it use?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] pci: Avoid assigning PCI resources that are below 0x1000
On Wed, Jun 05, 2019 at 07:26:44AM -0700, Bin Meng wrote:
> commit b7598a43f2b4 ("[PATCH] Avoid assigning PCI resources from
> zero address") only moved the bus lower address to 0x1000 if the
> given bus start address is zero. The comment said 0x1000 is a
> reasonable starting value, hence we'd better apply the same
> adjustment when the given bus start address is below 0x1000.
>
> Signed-off-by: Bin Meng
> 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 v2] lib: Makefile: build fdtdec_common.c when OF_LIBFDT selected
On Thu, Jun 06, 2019 at 07:59:16AM +, Peng Fan wrote: > When build SPL_OF_PLATDATA on i.MX6, meet issue the fdtdec_get_int > not defined, however fdtdec.c will use fdtdec_get_int, so let's > compile fdtdec_common.c when OF_LIBFDT selected. > > Since there is also SPL_OF_LIBFDT, so need to use > CONFIG_$(SPL_TPL_)OF_LIBFDT. > > Signed-off-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] arm: am335x-pdu001: Remove watchdog support
On Tue, Jun 11, 2019 at 10:39:52AM +0200, Felix Brack wrote: > This board does not require watchdog support. > > Signed-off-by: Felix Brack 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] rsa: reject images with unknown padding
On Fri, Jun 14, 2019 at 01:43:38PM -0400, Patrick Doyle wrote: > Previously we would store NULL in info->padding and jump to an illegal > instruction if an unknown value for "padding" was specified in the > device tree. > > Signed-off-by: Patrick Doyle 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] vexpress64: fix a typo of SPDX-License-Identifier
On Tue, Jun 18, 2019 at 12:25:51PM +0900, Masahiro Yamada wrote: > Misspelling of SPDX-License-Identifier is rather fatal than other > general typos, so must be fixed. > > This file spells SPDX-Licence-Identifier. >^ > > I also moved it to the very top of the file with // comment style. > > Detected by grepping the source tree: > > $ git grep --not -e SPDX-License-Identifier --and -e SPDX- > board/armltd/vexpress64/pcie.c: * SPDX-Licence-Identifier: GPL-2.0+ > > Signed-off-by: Masahiro Yamada > Acked-by: Liviu Dudau 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] cmd/led.c: fix typos in online help
On Mon, Jun 17, 2019 at 03:33:55PM +0200, Anatolij Gustschin wrote:
> Remove square brackets around label in state command description.
>
> Fixes: ea41b15617fa ("cmd/led: check subcommand "list" instead "l"")
> Signed-off-by: Anatolij Gustschin
> Reviewed-by: Heiko Schocher
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] arm64: zynqmp: Cover ultra96 dts file by MAINTAINERS fragment
On Thu, Jun 20, 2019 at 08:02:46AM +0200, Michal Simek wrote: > Avnet Ultra96 dts file should be also cover by MAINTAINERS fragment. > > Signed-off-by: Michal Simek 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] am335x, guardian: update the maintainer list
On Tue, Jun 18, 2019 at 01:54:02PM +, bollavarapumoses.christop...@in.bosch.com wrote: > From: Moses Christopher > > Signed-off-by: Moses Christopher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board: Arcturus: DM: Disable drivers without DM support.
On Mon, Jun 17, 2019 at 04:10:23PM -0400, Oleksandr Zhadan wrote: > Extra "not DM" controllers support is disabled. > u-boot BSP still good enough to upgrade and run images. > > Signed-off-by: Oleksandr Zhadan > Signed-off-by: Michael Durrant 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] travis.yml: Add buildman support for NXP's LS1028 & LX2160
On Wed, Jun 19, 2019 at 05:47:12PM +0530, Prabhakar Kushwaha wrote: > NXP's LS1028 and LX2160 platform build support added via buildman > in travis.yml. > > Signed-off-by: Prabhakar Kushwaha 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] config_distro_bootcmd: Init IDE devices
On Thu, Jun 20, 2019 at 04:31:35PM -0500, Joshua Watt wrote: > IDE devices are no longer automatically probed by u-boot, so it should > be done by the distro boot command before attempting to boot from IDE > (just like scsi and nvme) > > Signed-off-by: Joshua Watt 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] disk: part: Don't skip partition init
On Tue, Jun 18, 2019 at 09:53:04AM -0600, Robert Hancock wrote: > blk_get_device_by_str was skipping part_init when hw partition 0 was > selected because it is the default. However, this caused issues when > switching to a non-zero partition and then back to partition zero, as > stale data from the wrong partition was returned. > > Remove this optimization and call part_init regardless of the selected > partition. > > Signed-off-by: Robert Hancock Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi, On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: > > Hi Simon, > > Am 22.06.19 um 16:55 schrieb Simon Glass: > > I'd like to better understand the benefits of the 3-month timeline. > > It takes time to learn about a release, package and build it, test it on > various hardware, investigate and report errors, wait for feedback and > fixes, rinse and repeat with the next -rc. Many people don't do this as > their main job. > > If we shorten the release cycle, newer boards will get out faster (which > is good) but the overall quality of boards not actively worked on > (because they were working good enough before) will decay, which is bad. > The only way to counteract that would be to automatically test on real > hardware rather than just building, and doing that for all these masses > of boards seems unrealistic. Here I think you are talking about distributions. But why not just take every second release? I have certain had the experience of getting a board our of the cupboard and finding that the latest U-Boot doesn't work, nor the one before, nor the three before that. Are we actually seeing an improvement in regressions? I feel that testing is the only way to get that. Perhaps we should select a small subset of boards which do get tested, and actually have custodians build/test on those for every rc? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On Tue, 28 May 2019 at 11:33, Igor Opaniuk wrote: > > On Mon, May 27, 2019 at 5:58 PM Tom Rini wrote: > > > > On Mon, May 27, 2019 at 09:22:05AM +0200, Stefan Agner wrote: > > > On 27.05.2019 07:21, Igor Opaniuk wrote: > > > > Hi everyone, > > > > > > > > I've finally started looking into the cfb_console.c driver and it's > > > > conversion to DM_VIDEO after our initial discussion [1]. > > > > Unfortunately I've a bit underestimated the amount of effort that > > > > should be done, as mxsfb.c in the Linux mainline obviously pulls the > > > > whole core fb subsystem > > > > (drivers/video/fbdev/core), which can take a while and frankly I doubt > > > > that this is a proper way to do things here. > > > > > > Just wanted to mention that the Linux mxsfb fbdev driver is considered > > > deprecated. > > > > > > See: https://lore.kernel.org/patchwork/patch/950619/#1135990 > > > > > > Also note that the new DRM driver does use OF graph style bindings, see: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > > > > > > > > > > Taking into account that the deadline for DM_VIDEO conversion is > > > > 2019.07, it's unlikely that we will manage to do the full conversions > > > > this cfb_console driver and all dependent hw specific drivers in a > > > > proper way (where we can provide information about videomodes as > > > > properties in a proper nodes in DT). > > > > > > IMHO, if the deadline hinders us to do it properly, we should extend the > > > deadline. > > > > Agreed. We can always extend deadlines as needed when people are > > working to solve the problem, and we want it solved correctly. Thanks > > all! > > > > -- > > Tom > > Stefan, Anatolij, Tom, > > Thanks a lot for your input! Just want to mention that I am in full agreement with what was said here :-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] net: introduce packet capture support
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)
+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 */
+
+/**
+ * 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 capture
+ *
+ * @start if true, start capture if false stop capture
+ *
+ * @return 0 on success, -ERROR on error
+ */
+int pcap_start_stop(bool start);
+
+/**
+ * pcap_clear() - clear pcap capture buffer and statistics
+ *
+ * @return 0 on success, -ERROR on error
+ */
+int pcap_clear(void);
+
+/**
+ * pcap_print_status() - print status of pcap capture
+ *
+ * @return 0 on success, -ERROR on error
+ */
+int pcap_print_
[U-Boot] [PATCH 2/2] doc: pcap: add pcap cmd documentation
Add documentation for new "pcap" command. Signed-off-by: Ramon Fried --- 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. + +Usage example: + +# Initialize pcap capture to physical address (0x10) with maximum size of 10. +# Start capture +pcap start + +# Initialize network activity +env set ipaddr 10.0.2.15; env set serverip 10.0.2.2; tftp uImage64 + +# Stop capture +pcap stop + +# 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] [PATCH v2 2/2] doc: pcap: add pcap cmd documentation
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. + +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
Re: [U-Boot] [PATCH v2 1/3] mmc: Read sd card detect properties from DT
Hi Marek, Looks like CD is working fine with TI AM3358X SOC based targets. Ran a quick test after looking at the discussion, posting the results which might be of some help. In this test, mmc part is not printing the partition table of the previous card, instead it prints the partition table of the latest card which is inserted. Hope the test is inline with the discussion. Please ignore if the results doesn't make any sense. Tested on U-Boot v2019.07-rc1 8GB card inserted => mmc rescan => mmc part Partition Map for MMC device 0 -- Partition Type: DOS PartStart SectorNum Sectors UUIDType 1 2048262144 7d8cd224-01 0b Boot 2 264192 152596487d8cd224-02 83 => mmc info Device: OMAP SD/MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Bus Speed: 4800 Mode : SD High Speed (50MHz) Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes removed 8GB card and inserted 2GB card => mmc rescan => mmc part Partition Map for MMC device 0 -- Partition Type: DOS PartStart SectorNum Sectors UUIDType 1 2048262144 000c0116-01 0b Boot 2 264192 3647488 000c0116-02 83 => mmc info Device: OMAP SD/MMC Manufacturer ID: 1b OEM: 534d Name: 0 Bus Speed: 4800 Mode : SD High Speed (50MHz) Rd Block Len: 512 SD version 3.0 High Capacity: No Capacity: 1.9 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes Thanks Regards -- Suniel Mahesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Driver probing
Hi Aaron,
IMO, serial_init or serial_initialize will only probe for console
device - stdout-path in case of devicetree.
One should add lazy probe of all serial devices using uclass helpers
with board_late_init or last_stage_init in init_sequence_r.
In this case, to probe only this device check against "pci-bootcmd" name.
Regards,
Suneel
On Sat, Jun 22, 2019 at 2:17 AM Aaron Williams wrote:
>
> Hi all,
>
> I'm working on a driver for our ARM64 SOCs but am having an issue where the
> driver never gets probed. I added a bind function and the driver is getting
> bound and I have the appropriate entry in the device tree for it, but the
> probe function is never called.
>
> This is a pseudo driver in that there is no actual underlying hardware for it
> so there is no underlying PCI device. I'm sorry for the poor formatting, but
> my employer's email system is unusable.
>
> Any idea on why my driver is not getting probed? The compatible field should
> match and the driver is getting bound. The driver is a pseudo serial driver
> using shared memory for input.
>
> I have the following entry in the device tree for a memory mapped region:
>
> DTS:
> bootcmd: pci-bootcmd@0x03fff000 {
> /* remote bootcmd buffer location */
> compatible = "marvell,pci-bootcmd";
> reg = <0 0x03fff000 0 0x1000>;
> };
>
> My driver look like this:
>
> static int octeontx_bootcmd_probe(struct udevice *dev)
> {
> struct octeontx_bootcmd_data *bc;
> struct octeontx_pci_io_buf *buf;
> struct octeontx_bootcmd_platdata *plat = dev_get_platdata(dev);
>
> printf("%s(%s)\n", __func__, dev->name);
> return 0;
> }
> static int octeontx_bootcmd_bind(struct udevice *dev)
> {
> printf("%s(%s)\n", __func__, dev->name);
> return 0;
> }
>
> static const struct dm_serial_ops octeontx_bootcmd_ops = {
> .putc = octeontx_bootcmd_putc,
> .pending = octeontx_bootcmd_pending,
> .getc = octeontx_bootcmd_getc,
> };
>
> static const struct udevice_id octeontx_bootcmd_serial_id[] = {
> { .compatible = "marvell,pci-bootcmd", },
> { },
> };
>
> U_BOOT_DRIVER(octeontx_bootcmd) = {
> .name = "pci-bootcmd",
> .id = UCLASS_SERIAL,
> .of_match = of_match_ptr(octeontx_bootcmd_serial_id),
> .ofdata_to_platdata =
> of_match_ptr(octeontx_bootcmd_ofdata_to_platdata),
> .platdata_auto_alloc_size = sizeof(struct octeontx_bootcmd_platdata),
> .probe = octeontx_bootcmd_probe,
> .bind = octeontx_bootcmd_bind,
> .ops = &octeontx_bootcmd_ops,
> .priv_auto_alloc_size = sizeof(struct octeontx_bootcmd_data),
> .flags = DM_FLAG_PRE_RELOC,
> };
> ___
> 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] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi, Am 22.06.19 um 20:15 schrieb Simon Glass: > On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: >> Am 22.06.19 um 16:55 schrieb Simon Glass: >>> I'd like to better understand the benefits of the 3-month timeline. >> >> It takes time to learn about a release, package and build it, test it on >> various hardware, investigate and report errors, wait for feedback and >> fixes, rinse and repeat with the next -rc. Many people don't do this as >> their main job. >> >> If we shorten the release cycle, newer boards will get out faster (which >> is good) but the overall quality of boards not actively worked on >> (because they were working good enough before) will decay, which is bad. >> The only way to counteract that would be to automatically test on real >> hardware rather than just building, and doing that for all these masses >> of boards seems unrealistic. > > Here I think you are talking about distributions. But why not just > take every second release? You're missing my point: What good is it to do a release when you yourself consider it of such poor quality that you advise others not to take it? That has nothing per-se to do with who uses that release and whether you build it in OBS or locally. > I have certain had the experience of getting a board our of the > cupboard and finding that the latest U-Boot doesn't work, nor the one > before, nor the three before that. > > Are we actually seeing an improvement in regressions? I don't understand that question. The proposal, as I understood it, is to shorten the release cycle by one month, doing six instead of four releases. How could there be an improvement by leaving it as it is? My fear is that the change will make it _worse_, i.e. no improvement but rather risk of more regressions by switching to _two_ months. In this very same -rc4 thread I reported one such regression, and luckily a patch was quickly prepared to address it. It's not yet merged despite tested - review also takes time. > I feel that > testing is the only way to get that. Agreed. And my point was that testing takes time. Increasing the release frequency shortens the time for testing of each release. > Perhaps we should select a small subset of boards which do get tested, > and actually have custodians build/test on those for every rc? Many custodians are volunteers. You can't force them to test boards at a pace you dictate to them. Also, more frequent releases also increase the chances of a custodian/maintainer being on vacation during a release. And a working, say, BeagleBone doesn't make the user of a random other board any happier. ;-) Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4] gpio: add gpio-hog support
Hi Heiko,
On Wed, 12 Jun 2019 at 05:12, Heiko Schocher wrote:
>
> add gpio-hog support. GPIO hogging is a mechanism
> providing automatic GPIO request and configuration
> as part of the gpio-controller's driver probe function.
>
> for more infos see:
> doc/device-tree-bindings/gpio/gpio.txt
>
> Signed-off-by: Heiko Schocher
>
> ---
> clean travis build, see result:
> https://travis-ci.org/hsdenx/u-boot-test/builds/544040419
>
> Changes in v4:
> - rework as suggested by Patrick
> based on patch:
> http://patchwork.ozlabs.org/patch/1098913/
> use new UCLASS_NOP
> hog detection + DT parsing in gpio_post_bind() info saved in platdata
> gpio configuration for hog (request and set_dir) => probe function
Sorry for not getting to this earlier.
>
>
> Changes in v3:
> - probe now all gpio devices with gpio-hogs
> from board_r before board_late_init() call
> or if someone wants to access gpio-hog
> based gpios with gpio_hog_lookup_name()
> This is needed, because we cannot be sure,
> if a gpio device which contains gpio-hogs
> is probed.
> - add line-name property as Michal recommended
> - renamed gpio_priv_one into gpio_priv_one_hog
> and protected through CONFIG_DM_GPIO_HOG
>
> Changes in v2:
> - move gpio_hog() call from post_probe() to post_bind()
> call. Check if current gpio device has gpio-hog
> definitions, if so, probe it.
>
> common/board_r.c | 6 +
> doc/device-tree-bindings/gpio/gpio.txt | 55
> drivers/gpio/Kconfig | 10 ++
> drivers/gpio/gpio-uclass.c | 181 ++---
> include/asm-generic/gpio.h | 32 +
> 5 files changed, 268 insertions(+), 16 deletions(-)
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 150e8cd424..507da4c74a 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -49,6 +49,9 @@
> #include
> #include
> #include
> +#if defined(CONFIG_DM_GPIO_HOG)
> +#include
> +#endif
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -796,6 +799,9 @@ static init_fnc_t init_sequence_r[] = {
> #ifdef CONFIG_CMD_NET
> initr_ethaddr,
> #endif
> +#if defined(CONFIG_DM_GPIO_HOG)
> + gpio_hog_probe_all,
> +#endif
> #ifdef CONFIG_BOARD_LATE_INIT
> board_late_init,
> #endif
> diff --git a/doc/device-tree-bindings/gpio/gpio.txt
> b/doc/device-tree-bindings/gpio/gpio.txt
> index f7a158d858..e774439369 100644
> --- a/doc/device-tree-bindings/gpio/gpio.txt
> +++ b/doc/device-tree-bindings/gpio/gpio.txt
> @@ -210,3 +210,58 @@ Example 2:
> Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO
> ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2
> are named "foo" and "bar".
> +
> +3) GPIO hog definitions
> +---
> +
> +The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
> +providing automatic GPIO request and configuration as part of the
> +gpio-controller's driver probe function.
> +
> +Each GPIO hog definition is represented as a child node of the GPIO
> controller.
> +Required properties:
> +- gpio-hog: A property specifying that this child node represents a GPIO
> hog.
> +- gpios: Store the GPIO information (id, flags) for the GPIO to
> + affect.
> +
> + ! Not yet support more than one gpio !
> +
> +Only one of the following properties scanned in the order shown below.
> +- input: A property specifying to set the GPIO direction as input.
> +- output-low A property specifying to set the GPIO direction as output with
> + the value low.
> +- output-high A property specifying to set the GPIO direction as output with
> + the value high.
> +
> +Optional properties:
> +- line-name: The GPIO label name. If not present the node name is used.
This seems a strange name. I suppose this is what linux called it.
> +
> +Example:
> +
> +tca6416@20 {
> +compatible = "ti,tca6416";
> +reg = <0x20>;
> +#gpio-cells = <2>;
> +gpio-controller;
> +
> +env_reset {
> +gpio-hog;
> +input;
> +gpios = <6 GPIO_ACTIVE_LOW>;
> +};
> +boot_rescue {
> +gpio-hog;
> +input;
> +gpios = <7 GPIO_ACTIVE_LOW>;
Should have an example for line-name
> +};
> +};
> +
> +For the above Example you can than access the gpio in your boardcode
> +with:
> +
> +desc = gpio_hog_lookup_name("boot_rescue.gpio-hog");
Could we drop the .gpio-hog suffix? It doesn't seem necessary, but
perhaps you are worried about people getting confused otherwise?
Also this function should be passed a desc struct pointer, not return
static data.
> +if (desc) {
> +if (dm_gpio_get_value(desc))
You should check the error here.
dm_gpio_get_va
Re: [U-Boot] [PATCH v3 00/11] clk: Port Linux common clock framework [CCF] to U-boot (tag: 5.0-rc3)
Hi Lukasz, On Mon, 3 Jun 2019 at 08:22, Lukasz Majewski wrote: > > Hi Peng, > > > Hi All > > > > Will we force to use CCF in future? > > I do think yes (as fair as I can tell this is what the community > needs/agreed). > > > And Is there possibility this feature would land in v2019.07? > > Do you mean this release? We are -rc3 now so it is IMHO too late. > (The v2019.10-rc1 seems reasonable). > > The status is that Simon, had some comments for it and I need to > address them (however, recently I got less time to do that). > > > If not, I'll try to convert i.MX8MM CLK to no-CCF DM CLK version, > > since i.MX8MM has been pending for long time. > > The CCF was under discussion for some time for a reason - I would like > to avoid adding ad-hoc code and make it DM compliant (thanks Simon for > your feedback) and re-usable as much as possible. > > (I will try to do some work on it during this week). Just checking on the state of this since I have been a bit out of touch for a while. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 01/12] spl: fit: Add support for applying DT overlay
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote:
>
> From: Michal Simek
>
> doc/uImage.FIT/overlay-fdt-boot.txt is describing how to create FIT
> image with DT overlays in it.
> Add support for this feature to SPL.
>
> Here is the ZynqMP fragment where dtb points to full DT and dtbo is
> overlay which should be applied on the top of dtb.
> config {
> description = "ATF with full u-boot overlay";
> firmware = "atf";
> loadables = "uboot";
> fdt = "dtb", "dtbo";
> };
>
> The whole feature depends on OF_LIBFDT_OVERLAY which is adding +4kB code
> and 0 for platforms which are not enabling this feature.
>
> Signed-off-by: Michal Simek
> Signed-off-by: Jean-Jacques Hiblot
>
> ---
>
> Changes in v3:
> - Add a new config option: SPL_LOAD_FIT_APPLY_OVERLAY. By default, it is
> not selected.
>
> Changes in v2: None
>
> Kconfig | 10 ++
> common/spl/spl_fit.c | 27 +--
> 2 files changed, 35 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass
nits below
>
> diff --git a/Kconfig b/Kconfig
> index 5f5c5ccfd6..8197c9066a 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -398,6 +398,16 @@ config SPL_LOAD_FIT
> particular it can handle selecting from multiple device tree
> and passing the correct one to U-Boot.
>
> +config SPL_LOAD_FIT_APPLY_OVERLAY
> + bool "Enable SPL applying DT overlays from FIT"
> + depends on SPL_LOAD_FIT
> + select OF_LIBFDT_OVERLAY
> + default n
this is the default anyway so you can omit this line
> + help
> + The device tree is loaded from the FIT image. Allow the SPL is to
> + also load device-tree overlays from the FIT image an apply them
> + over the device tree.
Where are the instructions for this? At least add a pointer to a
README somewhere else.
> +
> config SPL_LOAD_FIT_FULL
> bool "Enable SPL loading U-Boot as a FIT"
> select SPL_FIT
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 87ecf0bb9e..3fbcb969f8 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -278,10 +278,10 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
> void *fit, int images, ulong base_offset)
> {
> struct spl_image_info image_info;
> - int node, ret;
> + int node, ret, index = 0;
>
> /* Figure out which device tree the board wants to use */
> - node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
> + node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index++);
> if (node < 0) {
> debug("%s: cannot find FDT node\n", __func__);
> return node;
> @@ -303,8 +303,31 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
> #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
> /* Try to make space, so we can inject details on the loadables */
> ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
> + if (ret < 0)
> + return ret;
> #endif
> +#if defined(CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY)
Can you use if (CONFIG_IS_ENABLED()) so that this builds with sandbox?
Actually we should really enable this with sandbox, too, so we can add a test.
> + for (; ; index++) {
> + node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP,
> index);
> + if (node < 0) {
> + debug("%s: No additional FDT node\n", __func__);
> + return 0;
> + }
>
> + ret = spl_load_fit_image(info, sector, fit, base_offset, node,
> +&image_info);
> + if (ret < 0)
> + return ret;
> +
> + ret = fdt_overlay_apply_verbose(spl_image->fdt_addr,
> + (void *)image_info.load_addr);
> + if (ret)
> + return ret;
> +
> + debug("%s: DT overlay %s applied\n", __func__,
> + fit_get_name(fit, node, NULL));
> + }
> +#endif
> return ret;
> }
>
> --
> 2.17.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 02/12] spl: fit: Make room in the FDT before applying overlays
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > Make room in the FDT before applying the overlay, otherwise it may fail if > the overlay is big. As the exact added size is not known in advance, just > add the size of the overlay. > Move after the end of the application of the overlays, the resize of the > FDT for the injection of the details on the loadables. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > common/spl/spl_fit.c | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 08/12] Makefile: Fix u-boot.itb generation when building outside the source tree
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > Include the object tree and the source tree in the search path of the > FIT compîler (dtc). This allows to use paths relative to the root of the > source or object trees in the ITS instead of working backward from the > actual location of the ITS. > It also allows to use a build directory different of the source directory. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > Makefile| 5 +++-- > board/theobroma-systems/lion_rk3368/fit_spl_atf.its | 6 +++--- > board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 8 > 3 files changed, 10 insertions(+), 9 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 05/12] spl: fit: be more verbose when an error occurs when applying the overlays
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > There are many ways the overlay application can fail. > 2 of them are probably the most common: > - the application itself failed. Usually this is comes from an unresolved > reference > - DTBO not available in FIT (could be because of a typo) > > In both case it is good to be more explicit about the error and at least > show which overlay is failing. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > common/spl/spl_fit.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 07/12] Makefile: Fix tests for CONFIG_SPL_LOAD_FIT and CONFIG_SPL_FIT_GENERATOR
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > The current tests do to handle well the cases where those variables are not > defined. When CONFIG_SPL_LOAD_FIT is not defined, U_BOOT_ITS gets defined > as an empty string. > Fixing it by using intermediate variables with the quotes removed > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > Makefile | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 06/12] Makefile.lib: include /__symbols__ in dtb if SPL_LOAD_FIT_APPLY_OVERLAY is enabled
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > In order to apply an overlay to a DTB. The DTB must have been generated > with the option '-@'. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > scripts/Makefile.lib | 4 > 1 file changed, 4 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 03/12] spl: fit: allocate a temporary buffer to load the overlays
Hi Jean-Jacques,
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote:
>
> If the node describing an overlay does not specify a load address, it will
> be loaded at the address previously used.
> Fixing it by allocating a temporary 64kB region that will be used as a
> default load address.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> common/spl/spl_fit.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index c1c982f002..b521ee68e6 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
should go at end
> +#include
> #include
>
> #ifndef CONFIG_SYS_BOOTM_LEN
> @@ -302,6 +303,16 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
> spl_image->fdt_addr = (void *)image_info.load_addr;
> #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
> #if defined(CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY)
> + void *tmpbuffer;
> + /*
> +* allocate 64kB of memory. This will be used to store the DT overlay
64KB
> +* before it is applied. It may not be used depending on how the
> +* overlay is stored.
> +*/
> + tmpbuffer = malloc(64 * 1024);
> + if (!tmpbuffer)
> + debug("%s: unable to allocate space for overlays\n",
> __func__);
Need to return an error here I think
> +
> for (; ; index++) {
> node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP,
> index);
> if (node < 0) {
> @@ -309,6 +320,7 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
> return 0;
> }
>
> + image_info.load_addr = (ulong)tmpbuffer;
> ret = spl_load_fit_image(info, sector, fit, base_offset, node,
> &image_info);
> if (ret < 0)
> @@ -327,6 +339,8 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
> debug("%s: DT overlay %s applied\n", __func__,
> fit_get_name(fit, node, NULL));
> }
> + if (tmpbuffer)
> + free(tmpbuffer);
Is this buffer freed if there is an error?
> #endif
> /* Try to make space, so we can inject details on the loadables */
> ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
> --
> 2.17.1
>
Regards,
Simon
___
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
Hi Eugeniu,
On Thu, 23 May 2019 at 16:33, 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
> ---
> v3:
> - [Simon Glass] Allow 'strsep' to modify the argv[n] string in-place
>rather than duplicating it with 'strdup'. Remove #include
> - [Simon Glass] Call bcb_is_misused() _once_ in do_bcb()
> - [Simon Glass] Report error codes if IO fails in do_bcb_{load,store}
> - [Simon Glass] Leave one empty line above top-level returns
>(note: checkpatch is indifferent about this)
> - [Simon Glass] Replace strncmp with '==' operator for single-character
>strings in do_bcb_test(), which reduces compiled object size
> - Reorder the functions to match the cmd_bcb_sub table
> - Improve error reporting:
>- s/Error: Unknown field/Error: Unknown bcb field/
>- s/debug Error: Unexpected BCB command/
> printf Error: 'bcb %s' not supported/
>- s/Error: BCB not loaded/Error: Please, load BCB first/
> - Make sure static analysis is clean:
>- cppcheck --force --enable=all --inconclusive
>- sparse/make C=2
>- make W=1
>- smatch
> - Re-test on R-Car H3ULCB-KF
> - Compile/boot/smoke-test on sandbox
> v2:
> - [Heinrich Schuchardt] Implement
Re: [U-Boot] [PATCH] cmd: nvedit: Add sub-command 'env info'
On Fri, 24 May 2019 at 16:20, Mark Jonas wrote: > > From: Leo Ruan > > Add sub-command 'env info' to display environment information: > - env_valid : is environment valid > - env_ready : is environment imported into hash table > - env_use_default : is default environment using > > This command can be optionally used for evaluation in scripts: > [-d] : evaluate whether default environment is used > [-p] : evaluate whether environment can be persisted > The result of multiple evaluations will be combined with AND. > > Signed-off-by: Leo Ruan > Signed-off-by: Mark Jonas > --- > cmd/Kconfig | 14 > cmd/nvedit.c | 108 > +++ > 2 files changed, 122 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: trace buffer may exceed 2GiB
On Fri, 14 Jun 2019 at 20:52, Heinrich Schuchardt wrote: > > Correct the debug output for the trace buffer size to accommodate trace > buffers exceeding 2GiB. > > Signed-off-by: Heinrich Schuchardt > --- > common/board_f.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] dm: i2c: Add a flag that needs to generate a stop bit
Hi,
On Fri, 24 May 2019 at 03:23, Chuanhua Han wrote:
>
> Usually the i2c bus needs to write the address of the register before
> reading the internal register data of the device (ignoring the
> transmission of the slave address).
>
> Generally, the stop signal is not needed before the register is read,
> but there is a special chip that needs this stop signal (such as
> pcf2127), this patch adds a flag that needs to generate a stop
> bit to determine whether the i2c host needs to generate a stop signal
> before reading the register data.
Does this mean that the chip does not comply with the i2c protocol?
Is it possible instead to so a write and then a read?
See dm_i2c_xfer().
>
> Signed-off-by: Biwen Li
> Signed-off-by: Chuanhua Han
> ---
> Changes in v2:
> - Split the original patch into 3 patches
> - Add detailed description information for each patch
>
> drivers/i2c/i2c-uclass.c | 2 ++
> include/i2c.h| 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
> index e47abf1833..18f7364d72 100644
> --- a/drivers/i2c/i2c-uclass.c
> +++ b/drivers/i2c/i2c-uclass.c
> @@ -141,6 +141,8 @@ int dm_i2c_read(struct udevice *dev, uint offset, uint8_t
> *buffer, int len)
> if (len) {
> ptr->addr = chip->chip_addr;
> ptr->flags = chip->flags & DM_I2C_CHIP_10BIT ? I2C_M_TEN : 0;
> + ptr->flags |= chip->flags & DM_I2C_CHIP_RD_NEED_STOP_BIT ?
> + I2C_M_RD_NEED_STOP_BIT : 0;
> ptr->flags |= I2C_M_RD;
> ptr->len = len;
> ptr->buf = buffer;
> diff --git a/include/i2c.h b/include/i2c.h
> index a5c760c711..beaa028349 100644
> --- a/include/i2c.h
> +++ b/include/i2c.h
> @@ -28,6 +28,7 @@ enum dm_i2c_chip_flags {
> DM_I2C_CHIP_10BIT = 1 << 0, /* Use 10-bit addressing */
> DM_I2C_CHIP_RD_ADDRESS = 1 << 1, /* Send address for each read byte
> */
> DM_I2C_CHIP_WR_ADDRESS = 1 << 2, /* Send address for each write byte
> */
> + DM_I2C_CHIP_RD_NEED_STOP_BIT= 1 << 3, /* Need generate stop bit */
> };
>
> struct udevice;
> @@ -87,6 +88,7 @@ enum dm_i2c_msg_flags {
> I2C_M_IGNORE_NAK= 0x1000, /* continue after NAK */
> I2C_M_NO_RD_ACK = 0x0800, /* skip the Ack bit on reads */
> I2C_M_RECV_LEN = 0x0400, /* length is first received byte */
> + I2C_M_RD_NEED_STOP_BIT = 0x0002, /* need generate stop bit */
> };
>
> /**
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: make call depth limit customizable
On Sun, 2 Jun 2019 at 12:30, Heinrich Schuchardt wrote: > > Up to now we had hard coded values for the call depth up to which trace > records are created: 200 for early tracing, 15 thereafter. UEFI > applications reach a call depth of 80 or above. > > Provide customizing settings for the call trace depth limit and the early > call trace depth limit. Use the old values as defaults. > > Signed-off-by: Heinrich Schuchardt > --- > lib/Kconfig | 15 +++ > lib/trace.c | 4 ++-- > 2 files changed, 17 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 04/12] spl: fit: Do not fail immediately if an overlay is not available
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > If one overlay that must be applied cannot be found in the FIT, the current > implementation stops applying the overlays. Let's make it skip only the > failing overlay instead. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > common/spl/spl_fit.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: conserve gd register
On Sun, 2 Jun 2019 at 12:05, Heinrich Schuchardt wrote: > > An UEFI application may change the value of the register that gd lives in. > But some of our functions like get_ticks() access this register. So we > have to set the gd register to the U-Boot value when entering a trace > point and set it back to the application value when exiting the trace > point. > > Signed-off-by: Heinrich Schuchardt > --- > lib/trace.c | 49 + > 1 file changed, 49 insertions(+) Ick. I can't think of a better idea. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 11/12] spl: fit: constify the output parameter of spl_fit_get_image_name()
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > There is no need for it to be non-constant. Making it constant, allows to > return constant string without warning. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > common/spl/spl_fit.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 10/12] Makefile: Query the SPL Fit Generator for its dependencies
On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > To reduce the complexity of the Makefile, let the generator tell what its > dependencies are. For this purpose use the "--deps" option. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > Makefile | 9 ++--- > arch/arm/mach-imx/mkimage_fit_atf.sh | 7 +++ > arch/arm/mach-rockchip/make_fit_atf.py | 8 > board/sunxi/mksunxi_fit_atf.sh | 5 + > 4 files changed, 22 insertions(+), 7 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 09/12] Makefile: Pass the board name to the FIT generator scripts
Hi, On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > Currently the FIT generator scripts are passed only a list of dtbs. > However some platforms may also require information about the board itself. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Changes in v3: None > Changes in v2: None > > Makefile | 2 +- > arch/arm/mach-imx/mkimage_fit_atf.sh | 3 ++- > arch/arm/mach-rockchip/make_fit_atf.py | 5 +++-- > board/sunxi/mksunxi_fit_atf.sh | 2 ++ > 4 files changed, 8 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass I wonder if these scripts should use binman? Regards, Simon ___ 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, 23 May 2019 at 16:33, 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 > --- > v3: > - Added 'Reviewed-by: Sam Protsenko' > v2: > - Newly pushed. No changes. > - https://patchwork.ozlabs.org/patch/1101108/ > --- > include/android_bootloader_message.h | 126 +++ > 1 file changed, 68 insertions(+), 58 deletions(-) > Reviewed-by: Simon Glass ___ 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
Hi Eugeniu,
On Thu, 23 May 2019 at 16:33, Eugeniu Rosca wrote:
>
> Rename:
> - doc/{README.avb2 => android/avb2.txt}
This should be in a separate patch since it isn't related to adding
the new docs, actually.
> - 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
> ---
> v3:
> - Newly pushed.
> ---
> doc/{README.avb2 => android/avb2.txt} | 0
> doc/android/bcb.txt | 89 +++
> .../fastboot.txt} | 0
> 3 files changed, 89 insertions(+)
> rename doc/{README.avb2 => android/avb2.txt} (100%)
> create mode 100644 doc/android/bcb.txt
> rename doc/{README.android-fastboot => android/fastboot.txt} (100%)
Looks good.
Reviewed-by: Simon Glass
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: Add basic Slim Bootloader payload support
On Thu, 20 Jun 2019 at 18:44, Park, Aiden wrote: > > This patch is to enable u-boot as a payload which runs on top of > Slim Bootloader(https://github.com/slimbootloader/slimbootloader) > boot firmware for x86 platforms. > > Added new SLIMBOOTLOADER SYS/VENDOR/TARGET CONFIG > - New arch/x86/cpu/slimbootloader directory with minimum codes > - New board/slimbootloader directory with minimum codes > - New dts, defconfig and configuration files > > Modified x86 files with minimum changes > - Kconfig and Makefile to enable new CONFIG > - arch_global_data structure to enable hob_list pointer > - init_cache_f_r to skip mtrr_commit > > Signed-off-by: Aiden Park > --- > arch/x86/Kconfig | 5 + > arch/x86/cpu/Makefile | 1 + > arch/x86/cpu/slimbootloader/Kconfig | 23 > arch/x86/cpu/slimbootloader/Makefile | 5 + > arch/x86/cpu/slimbootloader/car.S | 10 ++ > arch/x86/cpu/slimbootloader/slimbootloader.c | 117 ++ > .../cpu/slimbootloader/slimbootloader_hob.c | 67 ++ > .../slimbootloader/slimbootloader_serial.c| 66 ++ > arch/x86/dts/Makefile | 3 +- > arch/x86/dts/slimbootloader.dts | 33 + > .../asm/arch-slimbootloader/slimbootloader.h | 78 > arch/x86/include/asm/global_data.h| 2 +- > arch/x86/lib/asm-offsets.c| 2 +- > arch/x86/lib/init_helpers.c | 2 +- > board/slimbootloader/Kconfig | 21 > board/slimbootloader/slimbootloader/Kconfig | 51 > board/slimbootloader/slimbootloader/Makefile | 5 + > .../slimbootloader/slimbootloader.c | 60 + > .../slimbootloader/slimbootloader_start.S | 31 + > configs/slimbootloader_defconfig | 64 ++ > include/configs/slimbootloader.h | 54 > 21 files changed, 696 insertions(+), 4 deletions(-) > create mode 100644 arch/x86/cpu/slimbootloader/Kconfig > create mode 100644 arch/x86/cpu/slimbootloader/Makefile > create mode 100644 arch/x86/cpu/slimbootloader/car.S > create mode 100644 arch/x86/cpu/slimbootloader/slimbootloader.c > create mode 100644 arch/x86/cpu/slimbootloader/slimbootloader_hob.c > create mode 100644 arch/x86/cpu/slimbootloader/slimbootloader_serial.c > create mode 100644 arch/x86/dts/slimbootloader.dts > create mode 100644 arch/x86/include/asm/arch-slimbootloader/slimbootloader.h > create mode 100644 board/slimbootloader/Kconfig > create mode 100644 board/slimbootloader/slimbootloader/Kconfig > create mode 100644 board/slimbootloader/slimbootloader/Makefile > create mode 100644 board/slimbootloader/slimbootloader/slimbootloader.c > create mode 100644 board/slimbootloader/slimbootloader/slimbootloader_start.S > create mode 100644 configs/slimbootloader_defconfig > create mode 100644 include/configs/slimbootloader.h My main comment is that this needs some documetation. > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 70f939869a..3d57466a63 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -77,6 +77,9 @@ config VENDOR_GOOGLE > config VENDOR_INTEL > bool "Intel" > > +config VENDOR_SLIMBOOTLOADER > + bool "slimbootloader" > + > endchoice > > # subarchitectures-specific options below > @@ -104,6 +107,7 @@ source "board/efi/Kconfig" > source "board/emulation/Kconfig" > source "board/google/Kconfig" > source "board/intel/Kconfig" > +source "board/slimbootloader/Kconfig" > > # platform-specific options below > source "arch/x86/cpu/baytrail/Kconfig" > @@ -116,6 +120,7 @@ source "arch/x86/cpu/qemu/Kconfig" > source "arch/x86/cpu/quark/Kconfig" > source "arch/x86/cpu/queensbay/Kconfig" > source "arch/x86/cpu/tangier/Kconfig" > +source "arch/x86/cpu/slimbootloader/Kconfig" > > # architecture-specific options below > > diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile > index 85fd5e616e..a5c0113fa4 100644 > --- a/arch/x86/cpu/Makefile > +++ b/arch/x86/cpu/Makefile > @@ -48,6 +48,7 @@ obj-$(CONFIG_NORTHBRIDGE_INTEL_IVYBRIDGE) += ivybridge/ > obj-$(CONFIG_INTEL_QUARK) += quark/ > obj-$(CONFIG_INTEL_QUEENSBAY) += queensbay/ > obj-$(CONFIG_INTEL_TANGIER) += tangier/ > +obj-$(CONFIG_SYS_SLIMBOOTLOADER) += slimbootloader/ > obj-$(CONFIG_APIC) += lapic.o ioapic.o > obj-y += irq.o > ifndef CONFIG_$(SPL_)X86_64 > diff --git a/arch/x86/cpu/slimbootloader/Kconfig > b/arch/x86/cpu/slimbootloader/Kconfig > new file mode 100644 > index 00..e7513afd5b > --- /dev/null > +++ b/arch/x86/cpu/slimbootloader/Kconfig > @@ -0,0 +1,23 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# > +# Copyright (C) 2019 Intel Corporation > + > +if TARGET_SLIMBOOTLOADER > + > +config SYS_SLIMBOOTLOADER > + bool > + default y > + imply SYS_NS16550 > + imply AHCI_PCI > + imply SCSI > + imply SCSI_AHCI > + imply MMC > + i
Re: [U-Boot] pre_probe under struct driver
Hi Keerthy,
On Tue, 4 Jun 2019 at 14:01, Keerthy wrote:
>
> Hi Simon/Tom,
>
> I am looking at the device_probe function in drivers/core/device.c
>
> ret = uclass_pre_probe_device(dev);
> if (ret)
> goto fail;
>
> if (dev->parent && dev->parent->driver->child_pre_probe) {
> ret = dev->parent->driver->child_pre_probe(dev);
> if (ret)
> goto fail;
> }
>
> if (drv->ofdata_to_platdata && dev_has_of_node(dev)) {
> ret = drv->ofdata_to_platdata(dev);
> if (ret)
> goto fail;
> }
>
> /* Process 'assigned-{clocks/clock-parents/clock-rates}'
> properties */
> ret = clk_set_defaults(dev);
>
> In case of a device like MPU we would like setup voltage before setting
> the clocks and i was looking if we can have a pre_probe for a driver
> to do things before driver gets probed. Neither uclass_pre_probe_device
> nor dev->parent->driver->child_pre_probe benefit me in this case.
>
> Does my situation warrant adding a new hook to struct driver? Or are
> there instances of such handling already in u-boot.
For now, is it enough to probe the power driver from the clock driver?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] dm: spi: Convert Freescale ESPI driver to driver model
Hi,
On Fri, 24 May 2019 at 05:39, Chuanhua Han wrote:
>
> Modify the Freescale ESPI driver to support the driver model.
> Also resolved the following problems:
>
> = WARNING ==
> This board does not use CONFIG_DM_SPI. Please update
> the board before v2019.04 for no dm conversion
> and v2019.07 for partially dm converted drivers.
> Failure to update can lead to driver/board removal
> See doc/driver-model/MIGRATION.txt for more info.
>
> = WARNING ==
> This board does not use CONFIG_DM_SPI_FLASH. Please update
> the board to use CONFIG_SPI_FLASH before the v2019.07 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/MIGRATION.txt for more info.
>
>
> Signed-off-by: Chuanhua Han
> ---
> Changes in v2:
> - The fsl_espi driver support both OF_CONTROL and PLATDATA
>
> drivers/spi/fsl_espi.c | 454 +
> 1 file changed, 320 insertions(+), 134 deletions(-)
>
> diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
> index 7444ae1a06..a2f4027fca 100644
> --- a/drivers/spi/fsl_espi.c
> +++ b/drivers/spi/fsl_espi.c
> @@ -4,17 +4,27 @@
> *
> * Copyright 2010-2011 Freescale Semiconductor, Inc.
> * Author: Mingkai Hu (mingkai...@freescale.com)
> + *Chuanhua Han (chuanhua@nxp.com)
> */
>
> #include
> -
> #include
> #include
> #include
Please sort the includes - this one should go at the end
> +#include
> +#include
> +#include
> +
> +struct fsl_espi_platdata {
> + uint flags;
> + uint speed_hz;
> + uint num_chipselect;
> + fdt_addr_t regs_addr;
> +};
>
> -struct fsl_spi_slave {
> - struct spi_slave slave;
> +struct fsl_espi_priv {
> ccsr_espi_t *espi;
> + u32 speed_hz;
> unsigned intdiv16;
> unsigned intpm;
> int tx_timeout;
> @@ -25,9 +35,18 @@ struct fsl_spi_slave {
> unsigned intmax_transfer_length;
> };
>
> +struct fsl_spi_slave {
> + struct spi_slave slave;
> + struct fsl_espi_priv priv;
> +};
> +
> #define to_fsl_spi_slave(s) container_of(s, struct fsl_spi_slave, slave)
> +#define to_fsl_spi_priv(p) container_of(p, struct fsl_spi_slave, priv)
We shouldn't really need this. Can we just pass the containing stuct instead?
> #define US_PER_SECOND 100UL
>
> +/* default SCK frequency, unit: HZ */
> +#define FSL_ESPI_DEFAULT_SCK_FREQ 1000
> +
> #define ESPI_MAX_CS_NUM4
> #define ESPI_FIFO_WIDTH_BIT32
>
> @@ -62,121 +81,46 @@ struct fsl_spi_slave {
>
> #define ESPI_MAX_DATA_TRANSFER_LEN 0xFFF0
>
> -struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
> - unsigned int max_hz, unsigned int mode)
> -{
> - struct fsl_spi_slave *fsl;
> - sys_info_t sysinfo;
> - unsigned long spibrg = 0;
> - unsigned long spi_freq = 0;
> - unsigned char pm = 0;
> -
> - if (!spi_cs_is_valid(bus, cs))
> - return NULL;
> -
> - fsl = spi_alloc_slave(struct fsl_spi_slave, bus, cs);
> - if (!fsl)
> - return NULL;
> -
> - fsl->espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
> - fsl->mode = mode;
> - fsl->max_transfer_length = ESPI_MAX_DATA_TRANSFER_LEN;
> -
> - /* Set eSPI BRG clock source */
> - get_sys_info(&sysinfo);
> - spibrg = sysinfo.freq_systembus / 2;
> - fsl->div16 = 0;
> - if ((spibrg / max_hz) > 32) {
> - fsl->div16 = ESPI_CSMODE_DIV16;
> - pm = spibrg / (max_hz * 16 * 2);
> - if (pm > 16) {
> - pm = 16;
> - debug("Requested speed is too low: %d Hz, %ld Hz "
> - "is used.\n", max_hz, spibrg / (32 * 16));
> - }
> - } else
> - pm = spibrg / (max_hz * 2);
> - if (pm)
> - pm--;
> - fsl->pm = pm;
> -
> - if (fsl->div16)
> - spi_freq = spibrg / ((pm + 1) * 2 * 16);
> - else
> - spi_freq = spibrg / ((pm + 1) * 2);
> -
> - /* set tx_timeout to 10 times of one espi FIFO entry go out */
> - fsl->tx_timeout = DIV_ROUND_UP((US_PER_SECOND * ESPI_FIFO_WIDTH_BIT
> - * 10), spi_freq);
> -
> - return &fsl->slave;
> -}
> -
> -void spi_free_slave(struct spi_slave *slave)
> +#ifndef CONFIG_DM_SPI
It is more common to put #idef CONFIG_DM_SPI first with the old code last.
> +void spi_cs_activate(struct spi_slave *slave)
> {
> struct fsl_spi_slave *fsl = to_fsl_spi_slave(slave);
> - free(fsl);
> -}
> + ccsr_espi_t *espi = fsl->priv.espi;
> + unsigned int com = 0;
> + size_t data_len = fsl->priv.data_len;
>
> -int spi_claim_bus(struct spi_slave *s
Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】
Hi Andy, On Tue, 28 May 2019 at 09:34, Andy Yan wrote: > > Hi Simon: > > On 2019/5/23 上午3:39, Simon Glass wrote: > > Hi Andy, > > On Tue, 21 May 2019 at 19:56, Andy Yan wrote: > > Hi Simon: > > Simon Glass 于2019年5月22日周三 上午8:28写道： > > Hi Andy, > > On Tue, 21 May 2019 at 00:51, Andy Yan wrote: > > Hi Simon: > > On 2019/5/20 下午11:35, Simon Glass wrote: > > Hi Andy, > > On Mon, 20 May 2019 at 00:34, Andy Yan wrote: > > Hi Simon: > > On 2019/5/19 上午12:26, Simon Glass wrote: > > Hi Andy, > > Instead of this could you: > > - move ATF? > > All rockchip based arm64 ATF run from the start 64KB of dram as this > will give convenient for kernel manage the memory. > > On the other hand, change the ATF load address will break the > compatibility of the exiting firmware. > > - change the SPL load address so it is not in the way (since TPL can > load to any address) > > The SPL is loaded by bootrom after TPL back to bootrom, so the load > address if fixed by bootrom code. > > I think you are creating a nightmare here. If you have to do things > like this for older and smaller SoCs, OK. But it should not be used > for newer ones that can do things properly. > > Most rockchip based SOC sram is small, even in the future soc roadmap, > this situation will still exist, larger sram means more cost. > > I believe the RK3399 has 192KB. What is the minimum size in new chips? > > The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without > storage drive is 28KB. > The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT > SOC has the same limitation. > > OK, I see. > > > As for the current spl for rockchip soc in mainline, we use a workaround > by reserve large space at the head of spl(see > CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. > > Yes. > > As for my patch, the spl relocation is disabled default, we only enable > it on necessary platform, so it won't hurt others . > > Well it adds more code and complexity. Perhaps it makes sense to add > this, but I want to understand the need. > > The bootrom has so many limitations that it just creates pain. > > I know we can build mmc or other storage driver into TPL so we can use > tpl load spl on some platform that sram is big enough, but there are > also many rockchip soc has very small sram, so we tend to only do dram > initialization in tpl, and let bootrom load next stage . > > See above > > For the consideration of software development, we also want to keep TPL > clean, only do dram initialization(as it current status), this make our > internal dram team work more simple, they don't need to care about other > modules like mmc. > > Yes I understand this, but the boot ROM should be provided as a > library to call into: > > int mmc_read(void *addr, int start_block, int end_block) > int spi_read(void *addr, int start_block, int end_block) > > Then SPL or TPL can use it without all the strange limitations we have now. > > Since you probably already have these functions somewhere in the boot > ROM, you could implement this using a function table somewhere in the > ROM with a magic number before it, so that SPL can find it. > > The Bootrom do much more work than directly load the spl binary. It will do > somthing like checksum, look for the backup when the current image is > invalid, also including security check when secure boot is enabled. This is > why we did much work to add back_too_bootrom mechanism in mainline in 2017. > > Yes I understand that, but it is also quite inflexible, and creates > enormous problems with bootloaders. > > I am not suggesting that you remove functionality. I am suggesting > that you allow bootloaders to call into some of it, to reduce the > problems caused by the inflexible bootrom. > > > I checked with people who write bootrom code these days, as different chip > written by different people from different team, it took a bit long time to > figure out this. > > Yes , bootrom have storage access api like > mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not provide > a fixed table for these api, and the address for these api are different on > different chip, this means we have to list the api address chip by chip in > SPL code. There is another thing, as the bootrom code are written by > different person, the api interface don't keep constant: sfc_nor_read on one > chip is sfc_nor_read(void *addr, int start, int len), but on another chip is > sfc_nor_read(int start, void *addr, int len), this make things complicated. > > Also as what I mentioned before, the Bootrom do much more work than directly > load the spl binary, especially in secure boot mode, but the bootrom don't > want to export secure related api for security concern . > > So this seems not a good choice to reuse bootrom api in spl. While I understand what you are saying, I don't think it would be hard to add a little interface layer for each SoC which supports reading from each
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Andreas, On Sat, 22 Jun 2019 at 20:08, Andreas Färber wrote: > > Hi, > > Am 22.06.19 um 20:15 schrieb Simon Glass: > > On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: > >> Am 22.06.19 um 16:55 schrieb Simon Glass: > >>> I'd like to better understand the benefits of the 3-month timeline. > >> > >> It takes time to learn about a release, package and build it, test it on > >> various hardware, investigate and report errors, wait for feedback and > >> fixes, rinse and repeat with the next -rc. Many people don't do this as > >> their main job. > >> > >> If we shorten the release cycle, newer boards will get out faster (which > >> is good) but the overall quality of boards not actively worked on > >> (because they were working good enough before) will decay, which is bad. > >> The only way to counteract that would be to automatically test on real > >> hardware rather than just building, and doing that for all these masses > >> of boards seems unrealistic. > > > > Here I think you are talking about distributions. But why not just > > take every second release? > > You're missing my point: What good is it to do a release when you > yourself consider it of such poor quality that you advise others not to > take it? Who said that? Your point, I thought, was that people didn't have time to test it? > > That has nothing per-se to do with who uses that release and whether you > build it in OBS or locally. > > > I have certain had the experience of getting a board our of the > > cupboard and finding that the latest U-Boot doesn't work, nor the one > > before, nor the three before that. > > > > Are we actually seeing an improvement in regressions? > > I don't understand that question. The proposal, as I understood it, is > to shorten the release cycle by one month, doing six instead of four > releases. How could there be an improvement by leaving it as it is? My > fear is that the change will make it _worse_, i.e. no improvement but > rather risk of more regressions by switching to _two_ months. > > In this very same -rc4 thread I reported one such regression, and > luckily a patch was quickly prepared to address it. It's not yet merged > despite tested - review also takes time. > > > I feel that > > testing is the only way to get that. > > Agreed. And my point was that testing takes time. Increasing the release > frequency shortens the time for testing of each release. > > > Perhaps we should select a small subset of boards which do get tested, > > and actually have custodians build/test on those for every rc? > > Many custodians are volunteers. You can't force them to test boards at a > pace you dictate to them. Also, more frequent releases also increase the > chances of a custodian/maintainer being on vacation during a release. > > And a working, say, BeagleBone doesn't make the user of a random other > board any happier. ;-) Another question...how much do people care about the latest and greatest features? Perhaps we should be merging patches frequently, but creating a release branch separate from master? The current process seems very very slow to me. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] regulator: Allow autosetting fixed regulators
On Wed, 12 Jun 2019 at 07:32, Sven Schwermer wrote: > > Fixed regulators don't have a set_value method. Therefore, trying to > set their value will always return -ENOSYS. > > Signed-off-by: Sven Schwermer > Cc: Jaehoon Chung > Cc: Peng Fan > --- > drivers/power/regulator/regulator-uclass.c | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Simon Glass It should be possible to create a simple test for this in test/dm/regulator.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 12/12] spl: fit: Allow the board to tell if more images must be loaded from FIT
Hi Jean-Jacques, On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > spl_fit_get_image_name() is used to get the names of the images that the > SPL must load from the FIT. It relies on the content of a property present > in the FIT. The list of images is thus statically defined in the FIT. > With this scheme, it becomes quickly hard to manage combinations of more > than a hand few of images. > To address this problem, give the board-level code the opportunity to > add to the list of images. The images from the FIT property are loaded > first, and then the board_fit_get_additionnal_images() is called to > get more image names. > > Signed-off-by: Jean-Jacques Hiblot > > --- > > Changes in v3: > - removed the RFC prefix. This work will be needed soon by TI's AM65x > platform. and can probably benefit other modular platforms > - removed the last patch that provided an example of how to use this with > on a DRA76. > - removed the patch that made u-boot.img a symlink to u-boot.itb because > it breaks the build of many platforms (because files required to build the > ITB are missing) > - removed the patch to reduce the footprint of the am335x SPL. (already > merged) > - Made the boot flow more permissive (don't fail immediately if an overlay > is not present) and more verbose when an error occures > - handle the dependencies of the FIT generation in a more generic way > - use a dedicated kconfig option to enable the application of the overlays > by the SPL. > > Changes in v2: > - reworked board_fit_get_additionnal_images() and how it used in spl_fit.c > - removed dtbo generation from dtso files and use .dts extension for the > overlays > - add dynamic allocation usage in a separate patch > - defconfig change for the am335x_evm > > common/spl/spl_fit.c | 28 +--- > include/spl.h| 16 > 2 files changed, 41 insertions(+), 3 deletions(-) > Can we instead use driver mode for this? E.g. there is a board uclass which could have functionality added. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] clk: add support for clk_is_match()
On Mon, 3 Jun 2019 at 14:23, Sekhar Nori wrote: > > Add support for clk_is_match() which is required to > know if two clock pointers point to the same exact > physical clock. > > Also add a unit test for the new API. > > Reviewed-by: Lokesh Vutla > Signed-off-by: Sekhar Nori > --- > drivers/clk/clk-uclass.c | 13 + > include/clk.h| 13 + > test/dm/clk.c| 1 + > 3 files changed, 27 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] regulator: Allow enabling GPIO regulator
On Wed, 12 Jun 2019 at 09:26, Sven Schwermer wrote: > > Drivers need to be able to enable regulators that may be implemented as > GPIO regulators. Example: fsl_esdhc enables the vqmmc supply which is > commonly implemented as a GPIO regulator in order to switch between I/O > voltage levels. > > Signed-off-by: Sven Schwermer > --- > drivers/power/regulator/Kconfig | 2 ++ > drivers/power/regulator/gpio-regulator.c | 18 +- > 2 files changed, 19 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass Same comment about naming. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
On 6/22/19 8:15 PM, Simon Glass wrote: Hi, On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: Hi Simon, Am 22.06.19 um 16:55 schrieb Simon Glass: I'd like to better understand the benefits of the 3-month timeline. It takes time to learn about a release, package and build it, test it on various hardware, investigate and report errors, wait for feedback and fixes, rinse and repeat with the next -rc. Many people don't do this as their main job. If we shorten the release cycle, newer boards will get out faster (which is good) but the overall quality of boards not actively worked on (because they were working good enough before) will decay, which is bad. The only way to counteract that would be to automatically test on real hardware rather than just building, and doing that for all these masses of boards seems unrealistic. Here I think you are talking about distributions. But why not just take every second release? I have certain had the experience of getting a board our of the cupboard and finding that the latest U-Boot doesn't work, nor the one before, nor the three before that. Are we actually seeing an improvement in regressions? I feel that testing is the only way to get that. Perhaps we should select a small subset of boards which do get tested, and actually have custodians build/test on those for every rc? What I have been doing before all my recent pull requests is to boot both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via bootefi and GRUB. To make this easier I am using a Raspberry with a relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire) controlling the system under test, cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large What would be needed is scripts to automate the testing including all the Python tests. It would make sense to have such test automation for all of our architectures similar to what Kernel CI (https://kernelci.org/) does. Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] regulator: Factor out common enable code
Hi, On Wed, 12 Jun 2019 at 09:26, Sven Schwermer wrote: > > In preparation of being able to enable/disable GPIO regulators, the > code that will be shared among the two kinds to regulators is factored > out into its own source files. > > Signed-off-by: Sven Schwermer > --- > drivers/power/regulator/Kconfig| 10 +++ > drivers/power/regulator/Makefile | 1 + > drivers/power/regulator/common-regulator.c | 80 ++ > drivers/power/regulator/common-regulator.h | 27 > drivers/power/regulator/fixed.c| 75 ++-- > 5 files changed, 124 insertions(+), 69 deletions(-) > create mode 100644 drivers/power/regulator/common-regulator.c > create mode 100644 drivers/power/regulator/common-regulator.h This looks fine but I think regulator_common.c (and the regulator functions too) would be better. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] rtc: pcf2127: Fixed bug with rtc settings and getting error time
Hi, On Fri, 24 May 2019 at 03:23, Chuanhua Han wrote: > > The previous pcf2127 RTC chip could not read and set the correct time. > When reading the data of internal registers, the read address was the > value of register plus 1. This is because this chip requires the host > to send a stop signal after setting the register address and before > reading the register data. > > This patch sets the flag that the stop signal is needed and fixes the > bug of the original read and write time. > > Signed-off-by: Biwen Li > Signed-off-by: Chuanhua Han > --- > Changes in v2: > - Split the original patch into 3 patches > - Add detailed description information for each patch > > drivers/rtc/pcf2127.c | 18 ++ > 1 file changed, 10 insertions(+), 8 deletions(-) Can you modify this to use i2c_xfer() so that separate transactions are done? Regards, SImon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】
Hi, On Tue, 28 May 2019 at 09:47, Andy Yan wrote: > > Hi Simon: > > On 2019/5/23 上午3:39, Simon Glass wrote: > > Hi Andy, > > On Tue, 21 May 2019 at 19:43, Andy Yan wrote: > > Hi Andre: > > Andre Przywara 于2019年5月20日周一 下午11:59写道： > > On Mon, 20 May 2019 14:34:01 +0800 > Andy Yan wrote: > > Hi, > > On 2019/5/19 上午12:26, Simon Glass wrote: > > Hi Andy, > > Instead of this could you: > > - move ATF? > > All rockchip based arm64 ATF run from the start 64KB of dram as this > will give convenient for kernel manage the memory. > > This is just BL31 of ATF, right? > ATF recently gained PIE support for BL31 [1], so by just enabling this in > platform.mk you will get a relocatable BL31 image, with a very minimal > runtime linker. Worked out of the box on Allwinner for me, but YMMV. > So you could load newer ATF builds everywhere. > > > This is not the root case, actually we want put ATF as close as possible to > the start of dram, this give linux kernel convenient to manage the memory. > > But instead of 64KB you could put it at 32KB or 128KB. It's still in > the first 1MB. Linux won't care, right? > > > > Does that help you? > > On the other hand, change the ATF load address will break the > compatibility of the exiting firmware. > > I am not sure what you mean with "compatibility of existing firmware"? > Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) > into one image? And there would be no real mix and match, with older > pre-compiled builds? So by changing the ATF base address and the load > address in TPL at the same time you won't have issues? > > I mean older pre-compiled builds published by rockchip rkbin [1], many > projects and popular boards directly use this , for example Armbian. How to > change the base address of the pre-build binary? > [1] https://github.com/rockchip-linux/rkbin > > Perhaps I am misunderstanding your intent here, but mainline U-Boot > should not be bound to the design decisions of old closed-source > binaries. > > Indeed rockchip have submit the ATF support for rockchip platforms to ATF > mainline. But the situation is: we see many people like directly use the > pre-build binary from rkbin, they are used on many popular boards and > projects. Armbian is one of the example for this[0] , it use mainline u-boot, > but use atf from rkbin for some boards. > > So we are really care about the compatibility. OK I understand that. But perhaps for your newer chips you can start using U-Boot SPL instead of rkbin? Then, we can move away from the limitations. > > [0]https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf > > [...] > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] dm: core: add support for getting register address and size
On Mon, 3 Jun 2019 at 14:23, Sekhar Nori wrote: > > Current dev_read_*() API lacks support to get address and size > of a "reg" property by name or index. Add support for the same. > > Livetree support has been added but not tested on real hardware. > > The existing unit tests testing reading address from device-tree > have been updated to test address as well as size. > > Reviewed-by: Lokesh Vutla > Signed-off-by: Sekhar Nori > --- > drivers/core/fdtaddr.c | 17 + > drivers/core/read.c| 20 > include/dm/fdtaddr.h | 18 ++ > include/dm/read.h | 41 + > test/dm/test-fdt.c | 16 > 5 files changed, 108 insertions(+), 4 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: undefined reference to `trace_early_init'
On Sat, 1 Jun 2019 at 23:59, Heinrich Schuchardt wrote: > > Compiling with TRACE but without TRACE_EARLY results in an error > aarch64-linux-gnu-ld.bfd: > common/built-in.o:(.rodata.init_sequence_f+0x10): > undefined reference to `trace_early_init' > > trace_early_init() should not be called if CONFIG_TRACE_EARLY is not > defined. > > Signed-off-by: Heinrich Schuchardt > --- > common/board_f.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] disk: part: avoid undefined reference to `__udivmoddi4'
On Sun, 2 Jun 2019 at 09:36, Heinrich Schuchardt wrote: > > When compiling with FTRACE=1 an error > > ld.bfd: disk/built-in.o: in function `lba512_muldiv': > disk/part.c:114: undefined reference to `__udivmoddi4 > > occurred. > > Use '>> 11' instead of '/ 2048' to avoid the division. > > Signed-off-by: Heinrich Schuchardt > --- > disk/part.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Looks OK but I think you should rename div_by to shift_right, or similar. - SImon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt wrote: > > There is no good reason to limit the trace buffer to 2GiB on a 64bit > system. Adjust the types of the relevant parameters. > > Signed-off-by: Heinrich Schuchardt > --- > cmd/trace.c | 10 -- > include/trace.h | 6 +++--- > lib/trace.c | 14 +++--- > tools/proftool.c | 4 ++-- > 4 files changed, 16 insertions(+), 18 deletions(-) Wow it's going to take a very long time to transfer that much data over your network. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] disk: part: avoid undefined reference to `__udivmoddi4'
On 6/22/19 9:10 PM, Simon Glass wrote: On Sun, 2 Jun 2019 at 09:36, Heinrich Schuchardt wrote: When compiling with FTRACE=1 an error ld.bfd: disk/built-in.o: in function `lba512_muldiv': disk/part.c:114: undefined reference to `__udivmoddi4 occurred. Use '>> 11' instead of '/ 2048' to avoid the division. Signed-off-by: Heinrich Schuchardt --- disk/part.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Looks OK but I think you should rename div_by to shift_right, or similar. Thanks for reviewing. The patch is already merged. I will send a new patch to rename the parameter. Regards Heinrcih ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
On 6/22/19 9:10 PM, Simon Glass wrote: On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt wrote: There is no good reason to limit the trace buffer to 2GiB on a 64bit system. Adjust the types of the relevant parameters. Signed-off-by: Heinrich Schuchardt --- cmd/trace.c | 10 -- include/trace.h | 6 +++--- lib/trace.c | 14 +++--- tools/proftool.c | 4 ++-- 4 files changed, 16 insertions(+), 18 deletions(-) Wow it's going to take a very long time to transfer that much data over your network. Thanks for reviewing. I am writing files with the traces to the mounted file system. I activated traces in lib/efi_loader only and found several hundred thousand function calls just to start Shell.efi which ended up in exceeding the trace buffer. This is why want to lift unnecessary restrictions. What I still need to write is a script to analyze the traces to calculate the gross and the net time spent in each function. Regards Heinrich Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
On 6/22/19 9:12 PM, Heinrich Schuchardt wrote: > On 6/22/19 8:15 PM, Simon Glass wrote: >> Hi, >> >> On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: >>> >>> Hi Simon, >>> >>> Am 22.06.19 um 16:55 schrieb Simon Glass: I'd like to better understand the benefits of the 3-month timeline. >>> >>> It takes time to learn about a release, package and build it, test it on >>> various hardware, investigate and report errors, wait for feedback and >>> fixes, rinse and repeat with the next -rc. Many people don't do this as >>> their main job. >>> >>> If we shorten the release cycle, newer boards will get out faster (which >>> is good) but the overall quality of boards not actively worked on >>> (because they were working good enough before) will decay, which is bad. >>> The only way to counteract that would be to automatically test on real >>> hardware rather than just building, and doing that for all these masses >>> of boards seems unrealistic. >> >> Here I think you are talking about distributions. But why not just >> take every second release? >> >> I have certain had the experience of getting a board our of the >> cupboard and finding that the latest U-Boot doesn't work, nor the one >> before, nor the three before that. >> >> Are we actually seeing an improvement in regressions? I feel that >> testing is the only way to get that. >> >> Perhaps we should select a small subset of boards which do get tested, >> and actually have custodians build/test on those for every rc? > > What I have been doing before all my recent pull requests is to boot > both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via > bootefi and GRUB. To make this easier I am using a Raspberry with a > relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire) > controlling the system under test, > cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large > What would be needed is scripts to automate the testing including all > the Python tests. > > It would make sense to have such test automation for all of our > architectures similar to what Kernel CI (https://kernelci.org/) does. So who's gonna set it up and host it ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Simon, Am 22.06.19 um 21:14 schrieb Simon Glass: > On Sat, 22 Jun 2019 at 20:08, Andreas Färber wrote: >> Am 22.06.19 um 20:15 schrieb Simon Glass: >>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: Am 22.06.19 um 16:55 schrieb Simon Glass: > I'd like to better understand the benefits of the 3-month timeline. It takes time to learn about a release, package and build it, test it on various hardware, investigate and report errors, wait for feedback and fixes, rinse and repeat with the next -rc. Many people don't do this as their main job. If we shorten the release cycle, newer boards will get out faster (which is good) but the overall quality of boards not actively worked on (because they were working good enough before) will decay, which is bad. The only way to counteract that would be to automatically test on real hardware rather than just building, and doing that for all these masses of boards seems unrealistic. >>> >>> Here I think you are talking about distributions. But why not just >>> take every second release? >> >> You're missing my point: What good is it to do a release when you >> yourself consider it of such poor quality that you advise others not to >> take it? > > Who said that? You, quoted above. In response to my concerns about decreasing quality you suggested to take only every second release. That doesn't improve the quality of either. It implies that one may have such bad quality that people should skip it and yet does nothing to improve the next. > Your point, I thought, was that people didn't have time to test it? Not quite, I was talking about the full build-test-report-fix cycle taking its time. Bugs in one -rc don't necessarily get detected and fixed in time for the next -rc. And I fail to see how your suggestion of skipping releases gives them more time to test before the U-Boot release. That would rather be an argument for slowing down the U-Boot release cycle beyond 3 months (which I'm not asking). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mmc: Read sd card detect properties from DT
On 6/22/19 8:58 PM, Suniel Mahesh wrote: > Hi Marek, Hi, > Looks like CD is working fine with TI AM3358X SOC based targets. Yes, it does. > Ran a quick test after looking at the discussion, posting the results which > might be of some help. I think you misunderstood my proposal. mmc rescan ; mmc part ; ; mmc rescan ; mmc part obviously works, because of the second mmc rescan. Try without the second mmc rescan, you'll get the old results. My proposal was suggesting that we add the ability to poll CD into the u-boot main loop and detect the card replacement in the background, thus making "mmc rescan" basically a no-op. Then, if the user replaced the card, the user won't have to worry about running "mmc rescan" or forgetting to do so. > In this test, mmc part is not printing the partition table of the previous > card, instead it prints > the partition table of the latest card which is inserted. > > Hope the test is inline with the discussion. Please ignore if the results > doesn't make any sense. > > Tested on U-Boot v2019.07-rc1 > > 8GB card inserted > > => mmc rescan > => mmc part > > Partition Map for MMC device 0 -- Partition Type: DOS > > PartStart SectorNum Sectors UUIDType > 1 2048262144 7d8cd224-01 0b Boot > 2 264192 152596487d8cd224-02 83 > > => mmc info > Device: OMAP SD/MMC > Manufacturer ID: 3 > OEM: 5344 > Name: SS08G > Bus Speed: 4800 > Mode : SD High Speed (50MHz) > Rd Block Len: 512 > SD version 3.0 > High Capacity: Yes > Capacity: 7.4 GiB > Bus Width: 4-bit > Erase Group Size: 512 Bytes > > > removed 8GB card and inserted 2GB card > > => mmc rescan > => mmc part > > Partition Map for MMC device 0 -- Partition Type: DOS > > PartStart SectorNum Sectors UUIDType > 1 2048262144 000c0116-01 0b Boot > 2 264192 3647488 000c0116-02 83 > => mmc info > Device: OMAP SD/MMC > Manufacturer ID: 1b > OEM: 534d > Name: 0 > Bus Speed: 4800 > Mode : SD High Speed (50MHz) > Rd Block Len: 512 > SD version 3.0 > High Capacity: No > Capacity: 1.9 GiB > Bus Width: 4-bit > Erase Group Size: 512 Bytes > > Thanks > > Regards > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH PATCH v3 00/12] Add support for applications of overlays in SPL
Hi Jean-Jacques, On Thu, 23 May 2019 at 11:39, Jean-Jacques Hiblot wrote: > > > The purpose of this series is to provide the SPL with ability to apply > overlays for u-boot. this is only a RFC so far, to get a feedback on the > approach. > > Our use-case is the support of the daughter boards of the AM65x EVM. In > Linux, each board is supported by a unique overlay. The presence of the > boards is detected at runtime, and some useful features (like USB) are > implemented on those daughter boards. Instead of providing multiple dtbs > and fall in a combinatorial pit, we propose to use DT overlays. > > Patch #1 "spl: fit: Add support for applying DT overlay" has been posted > a few weeks ago by Michal Simek. > Patch #2 to #5 amend Michal's patch. > Patch #6 to #8 are simple fixes for the Makefile > Patch #9 is not required but relates to this series and will be required > later by the AM6x platform > Patch #10 is used to reduce the complexity of the Makefile by having FIT > generator scripts provide their dependencies > Patch #12 adds a way to dynamically select the DT overlays. That is were we > would use HW detection to select the required overlays. In that case, the > board-level code tells what overlay it needs (it gives the name of the > node). > > On arm, if overlay are supported, this series increases the size of the SPL > by 3.2 kB. > > Travis build : https://travis-ci.org/jjhiblot/u-boot/builds/535686392 > For a strange reason, buildman on travis show errors for sun8i ans sun50i, > but pass when I run it locally. > > Changes in v3: > - Add a new config option: SPL_LOAD_FIT_APPLY_OVERLAY. By default, it is > not selected. > - removed the RFC prefix. This work will be needed soon by TI's AM65x > platform. and can probably benefit other modular platforms > - removed the last patch that provided an example of how to use this with > on a DRA76. > - removed the patch that made u-boot.img a symlink to u-boot.itb because > it breaks the build of many platforms (because files required to build the > ITB are missing) > - removed the patch to reduce the footprint of the am335x SPL. (already > merged) > - Made the boot flow more permissive (don't fail immediately if an overlay > is not present) and more verbose when an error occures > - handle the dependencies of the FIT generation in a more generic way > - use a dedicated kconfig option to enable the application of the overlays > by the SPL. > > Changes in v2: > - reworked board_fit_get_additionnal_images() and how it used in spl_fit.c > - removed dtbo generation from dtso files and use .dts extension for the > overlays > - add dynamic allocation usage in a separate patch > - defconfig change for the am335x_evm > > Jean-Jacques Hiblot (11): > spl: fit: Make room in the FDT before applying overlays > spl: fit: allocate a temporary buffer to load the overlays > spl: fit: Do not fail immediately if an overlay is not available > spl: fit: be more verbose when an error occurs when applying the > overlays > Makefile.lib: include /__symbols__ in dtb if > SPL_LOAD_FIT_APPLY_OVERLAY is enabled > Makefile: Fix tests for CONFIG_SPL_LOAD_FIT and > CONFIG_SPL_FIT_GENERATOR > Makefile: Fix u-boot.itb generation when building outside the source > tree > Makefile: Pass the board name to the FIT generator scripts > Makefile: Query the SPL Fit Generator for its dependencies > spl: fit: constify the output parameter of spl_fit_get_image_name() > spl: fit: Allow the board to tell if more images must be loaded from > FIT > > Michal Simek (1): > spl: fit: Add support for applying DT overlay > > Kconfig | 10 +++ > Makefile | 23 +++-- > arch/arm/mach-imx/mkimage_fit_atf.sh | 10 ++- > arch/arm/mach-rockchip/make_fit_atf.py| 13 ++- > board/sunxi/mksunxi_fit_atf.sh| 7 ++ > .../lion_rk3368/fit_spl_atf.its | 6 +- > .../puma_rk3399/fit_spl_atf.its | 8 +- > common/spl/spl_fit.c | 90 +-- > include/spl.h | 16 > scripts/Makefile.lib | 4 + > 10 files changed, 156 insertions(+), 31 deletions(-) How about a test that uses sandbox to apply some overlays? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v3, 5/5] mmc: fsl_esdhc_imx: drop useless code
Hi Lu,
On Mon, Jun 03, 2019 at 04:28:24AM +, Y.b. Lu wrote:
> Hi,
>
> > -Original Message-
> > From: Angelo Dureghello
> > Sent: 2019年5月31日 15:15
> > To: Y.b. Lu
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [v3, 5/5] mmc: fsl_esdhc_imx: drop useless code
> >
> > Hi Lu,
> >
> > On Fri, May 31, 2019 at 06:12:12AM +, Y.b. Lu wrote:
> > > Hi Angelo,
> > >
> > > > -Original Message-
> > > > From: Angelo Dureghello
> > > > Sent: 2019年5月31日 2:23
> > > > To: Y.b. Lu
> > > > Cc: u-boot@lists.denx.de; Stefano Babic ; Fabio
> > > > Estevam ; dl-uboot-imx ;
> > > > Albert Aribaud ; Eddy Petrișor
> > > > ; Akshay Bhat ;
> > Ken
> > > > Lin ; Heiko Schocher ;
> > > > Christian Gmeiner ; Stefan Roese
> > > > ; Patrick Bruenn ; Troy Kisky
> > > > ; Uri Mashiach
> > > > ; Nikita Kiryanov
> > > > ; Otavio Salvador ;
> > > > Andreas Geisreiter ; Ludwig Zenz
> > > > ; Eric Bénard ; Peng Fan
> > > > ; Jason Liu ; Ye Li
> > > > ; Adrian Alonso ; Alison Wang
> > > > ; thar...@gateworks.com; Ian Ray
> > > > ; Marcin Niestroj ;
> > > > Andrej Rosano ; Marek Vasut
> > ;
> > > > Lukasz Majewski ; Adam Ford ;
> > > > Olaf Mandel ; Martyn Welch
> > > > ; Ingo Schroeck
> > ;
> > > > Boris Brezillon ; Soeren Moch
> > > > ; Richard Hu ; Vanessa
> > > > Maegima ; Max Krummenacher
> > > > ; Stefan Agner
> > > > ; Markus Niebel
> > > > ; Breno Matheus Lima
> > > > ; Francesco Montefoschi
> > > > ; Parthiban Nallathambi
> > > > ; Albert ARIBAUD ;
> > > > Jagan Teki ; Raffaele RECALCATI
> > > > ; Simone CIANNI
> > > > ; Bhaskar Upadhaya
> > > > ; Vinitha V Pillai
> > > > ; Prabhakar Kushwaha
> > > > ; Rajesh Bhagat
> > ;
> > > > Antti Mäentausta ; Sébastien Szymanski
> > > > ; Lucile Quirion
> > > > ; Alexey Brodkin
> > > > ; Trevor Woerner ;
> > > > Anatolij Gustschin ; Denis Zalevskiy
> > > > ; Fabien Lahoudere
> > > > ; Joe Hershberger
> > > > ; Simon Goldschmidt
> > > > ; James Byrne
> > > >
> > > > Subject: Re: [v3, 5/5] mmc: fsl_esdhc_imx: drop useless code
> > > >
> > > > Hi Lu,
> > > >
> > > > On Tue, May 21, 2019 at 08:53:04AM +, Y.b. Lu wrote:
> > > > > Dropped useless code for i.MX eSDHC driver.
> > > > >
> > > > > Signed-off-by: Yangbo Lu
> > > > > ---
> > > > > Changes for v2:
> > > > > - Added this patch.
> > > > > Changes for v3:
> > > > > - None.
> > > > > ---
> > > > > drivers/mmc/fsl_esdhc_imx.c | 96
> > > > > ++---
> > > > > include/fsl_esdhc_imx.h | 4 --
> > > > > 2 files changed, 4 insertions(+), 96 deletions(-)
> > > > >
> > > > > diff --git a/drivers/mmc/fsl_esdhc_imx.c
> > > > > b/drivers/mmc/fsl_esdhc_imx.c index faf133390f..1c02e0eef1 100644
> > > > > --- a/drivers/mmc/fsl_esdhc_imx.c
> > > > > +++ b/drivers/mmc/fsl_esdhc_imx.c
> > > > > @@ -259,8 +259,7 @@ static int esdhc_setup_data(struct
> > > > > fsl_esdhc_priv *priv, struct mmc *mmc, {
> > > > > int timeout;
> > > > > struct fsl_esdhc *regs = priv->esdhc_regs; -#if
> > > > > defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \
> > > > > - defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
> > > > > +#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) ||
> > > > > +defined(CONFIG_IMX8M)
> > > > > dma_addr_t addr;
> > > > > #endif
> > > > > uint wml_value;
> > > > > @@ -273,8 +272,7 @@ static int esdhc_setup_data(struct
> > > > > fsl_esdhc_priv *priv, struct mmc *mmc,
> > > > >
> > > > > esdhc_clrsetbits32(®s->wml, WML_RD_WML_MASK,
> > wml_value);
> > > > > #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO -#if
> > > > > defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \
> > > > > - defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
> > > > > +#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) ||
> > > > > +defined(CONFIG_IMX8M)
> > > > > addr = virt_to_phys((void *)(data->dest));
> > > > > if (upper_32_bits(addr))
> > > > > printf("Error found for upper 32 bits\n"); @@
> > > > > -310,8
> > +308,7
> > > > @@
> > > > > static int esdhc_setup_data(struct fsl_esdhc_priv *priv, struct mmc
> > *mmc,
> > > > > esdhc_clrsetbits32(®s->wml, WML_WR_WML_MASK,
> > > > > wml_value << 16);
> > > > > #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO -#if
> > > > > defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \
> > > > > - defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
> > > > > +#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) ||
> > > > > +defined(CONFIG_IMX8M)
> > > > > addr = virt_to_phys((void *)(data->src));
> > > > > if (upper_32_bits(addr))
> > > > > printf("Error found for upper 32 bits\n"); @@
> > > > > -376,8
> > +373,7
> > > > @@
> > > > > static void check_and_invalidate_dcache_range
> > > > > unsigned end = 0;
> > > > > unsigned size = roundup(ARCH_DMA_MINALIGN,
> > > > > data->blocks*data->blocksize); -#if
> > > > > defined(
[U-Boot] [PATCH] ARM: am3517-evm: Remove manual ethernet reset code
The reset line going to the ethernet controller is controlled
by a global reset controlling multiple peripherals. There
is no need to manually invoke the reset.
Signed-off-by: Adam Ford
diff --git a/board/logicpd/am3517evm/am3517evm.c
b/board/logicpd/am3517evm/am3517evm.c
index 10031a4801..e799f80d81 100644
--- a/board/logicpd/am3517evm/am3517evm.c
+++ b/board/logicpd/am3517evm/am3517evm.c
@@ -114,7 +114,6 @@ static void am3517_evm_musb_init(void)
*/
int misc_init_r(void)
{
- volatile unsigned int ctr;
u32 reset;
#if !defined(CONFIG_DM_I2C)
@@ -126,35 +125,10 @@ int misc_init_r(void)
am3517_evm_musb_init();
- if (gpio_request(PHY_GPIO, "gpio_30") == 0) {
- /* activate PHY reset */
- gpio_direction_output(PHY_GPIO, 0);
- gpio_set_value(PHY_GPIO, 0);
-
- ctr = 0;
- do {
- udelay(1000);
- ctr++;
- } while (ctr < 300);
-
- /* deactivate PHY reset */
- gpio_set_value(PHY_GPIO, 1);
-
- /* allow the PHY to stabilize and settle down */
- ctr = 0;
- do {
- udelay(1000);
- ctr++;
- } while (ctr < 300);
-
- /* ensure that the module is out of reset */
- reset = readl(AM3517_IP_SW_RESET);
- reset &= (~CPGMACSS_SW_RST);
- writel(reset, AM3517_IP_SW_RESET);
-
- /* Free requested GPIO */
- gpio_free(PHY_GPIO);
- }
+ /* ensure that the Ethernet module is out of reset */
+ reset = readl(AM3517_IP_SW_RESET);
+ reset &= (~CPGMACSS_SW_RST);
+ writel(reset, AM3517_IP_SW_RESET);
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [BUG] incorrect crash dump output for thumbs mode
Hello Marek, please, have a look at arch/arm/lib/interrupts.c. If the processor is in thumbs mode when crashing the output is formatted in a different way than when not in thumbs mode, cf. dump_instr(). Is there something wrong with the thumbs mode detection? Well, try maybe objdump ? What is more plausible, that the above completely nonsensical disassembly actually works and the CPU triggers undefined instruction -- or that the CPU is actually in thumb mode (hint: imx6 u-boot builds are built in thumb2) and there's a bug in efi_device_path.c ? I think the later. I think maybe you should slow down and consider this option. On a Wandboard which is also imx I had a look at the output of exceptions: => exception unaligned data abort pc : [<8f7a2b1a>] lr : [<8f7ab1b7>] reloc pc : [<1780cb1a>]lr : [<178151b7>] sp : 8ed8c3f8 ip : 8f7a2b15 fp : 0002 r10: 8f7f81f0 r9 : 8ed95ea8 r8 : 8ed99488 r7 : 8f7ab109 r6 : r5 : 8ed8c3f9 r4 : 8f7f6358 r3 : 8ed9948c r2 : 0001 r1 : r0 : 8f7f6358 Flags: nzCv IRQs off FIQs off Mode SVC_32 Code: 8f7e1907 8f7e191f 8f7e193d f105466d (e9d50501) Resetting CPU ... cat u-boot.map .text.do_unaligned 0x1780cb140xe cmd/built-in.o objdump -S -D cmd/arm/exception.o : /* * The LDRD instruction requires the data source to be four byte aligned * even if strict alignment fault checking is disabled in the system * control register. */ asm volatile ( 0: 466dmov r5, sp 2: f105 0501 add.w r5, r5, #1 6: e9d5 6700 ldrdr6, r7, [r5] "MOV r5, sp\n" "ADD r5, #1\n" "LDRD r6, r7, [r5]\n"); return CMD_RET_FAILURE; } a: 2001movsr0, #1 c: 4770bx lr So there is a bug in arch/arm/lib/interrupts.c such that it does not detect thumb mode and outputs the code arround PC incorrectly. Macro thumb_mode(regs) returns 0 though the thumbs flag is set: CPSR: 21f3 THUMBS_FLAG: 0020 The reason is that in arch/arm/include/asm/proc-armv/ptrace.h we are checking non-existent CONFIG_ARM_THUMB. We should check CONFIG_IS_ENABLED(SYS_THUMB_BUILD). I will send a patch to correct this. With the patch applied the output is correct: => exception unaligned data abort pc : [<8f7a2b52>] lr : [<8f7ab1ef>] reloc pc : [<1780cb52>]lr : [<178151ef>] sp : 8ed8c3f8 ip : 8f7a2b4d fp : 0002 r10: 8f7f8228 r9 : 8ed95ea8 r8 : 8ed99488 r7 : 8f7ab141 r6 : r5 : 8ed8c3f9 r4 : 8f7f6390 r3 : 8ed9948c r2 : 0001 r1 : r0 : 8f7f6390 Flags: nzCv IRQs off FIQs off Mode SVC_32 (T) Code: 8f7e 466d f105 0501 (e9d5) 6700 Resetting CPU ... Thanks for rubbing my nose into it. Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARM: correct detection of thumbs mode
When a crash occurs in thumbs mode the crash dump is incorrect. This is due to the usage of a non-existing configuration variable CONFIG_ARM_THUMB in the definition of macro thumb_mode(regs). Use CONFIG_IS_ENABLED(SYS_THUMB_BUILD) to detect that the code has been compiled for thumbs mode. With the patch crash dumps indicate thumbs mode correctly. On a system with thumbs mode: => exception unaligned data abort pc : [<8f7a2b52>] lr : [<8f7ab1ef>] reloc pc : [<1780cb52>]lr : [<178151ef>] sp : 8ed8c3f8 ip : 8f7a2b4d fp : 0002 r10: 8f7f8228 r9 : 8ed95ea8 r8 : 8ed99488 r7 : 8f7ab141 r6 : r5 : 8ed8c3f9 r4 : 8f7f6390 r3 : 8ed9948c r2 : 0001 r1 : r0 : 8f7f6390 Flags: nzCv IRQs off FIQs off Mode SVC_32 (T) Code: 8f7e 466d f105 0501 (e9d5) 6700 The Flags line has '(T)' and in the Code line the output is in u16 groups. On a system without thumbs mode: => exception breakpoint prefetch abort pc : [<7ff5a5c8>] lr : [<7ff675ec>] reloc pc : []lr : [<0001b5ec>] sp : 7ee0ad80 ip : 7ff5a5cc fp : 7ff674cc r10: 0002 r9 : 7ef0bed8 r8 : 7ffd6214 r7 : 7ef0e080 r6 : r5 : 7ffd4090 r4 : r3 : 7ef0e084 r2 : 0001 r1 : r0 : 7ffd4090 Flags: nzCv IRQs off FIQs off Mode SVC_32 Code: e1a0500d e2855001 e1c560d0 e3a1 (e12fff1e) The Flags line does not show '(T)' and in the Code line the output is in u32 groups. Reported-by: Marek Vasut Signed-off-by: Heinrich Schuchardt --- arch/arm/include/asm/proc-armv/ptrace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/proc-armv/ptrace.h b/arch/arm/include/asm/proc-armv/ptrace.h index 183b00a087..e37ad8fd1f 100644 --- a/arch/arm/include/asm/proc-armv/ptrace.h +++ b/arch/arm/include/asm/proc-armv/ptrace.h @@ -86,7 +86,7 @@ struct pt_regs { #define user_mode(regs)\ (((regs)->ARM_cpsr & 0xf) == 0) -#ifdef CONFIG_ARM_THUMB +#if CONFIG_IS_ENABLED(SYS_THUMB_BUILD) #define thumb_mode(regs) \ (((regs)->ARM_cpsr & T_BIT)) #else -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
