Re: [U-Boot] [PATCH v3 05/13] regmap: Add support for polling on a register
Hi Tom, On 13/02/19 1:25 PM, Faiz Abbas wrote: > Hi Tom, > > On 12/02/19 2:28 PM, Faiz Abbas wrote: >> Add an API to continuously read a register until a condition is >> satisfied or a timeout occurs. >> >> Signed-off-by: Faiz Abbas >> Reviewed-by: Tom Rini >> --- >> include/regmap.h | 34 ++ >> 1 file changed, 34 insertions(+) > > I realize there already exists an implementation of this in latest > u-boot. So we'll have to drop this patch. Will post a new version based > on top of that implementation. > We should not have applied this. I will send a revert soon. Thanks, Faiz ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] arm: dts: h6: Add Beelink GS1 initial support
On Mon, Apr 15, 2019 at 2:58 AM Clément Péron wrote:
>
> Hi,
>
> On Sun, 14 Apr 2019 at 19:29, Jagan Teki wrote:
> >
> > On Fri, Apr 12, 2019 at 7:45 PM Clément Péron wrote:
> > >
> > > Beelink GS1 is an Allwinner H6 based TV box,
> > > which support:
> > > - Allwinner H6 Quad-core 64-bit ARM Cortex-A53
> > > - GPU Mali-T720
> > > - 2GB LPDDR3 RAM
> > > - 16GB eMMC
> > > - AXP805 PMIC
> > > - 1Gbps GMAC via RTL8211E
> > > - USB 2.0 and 3.0 Host
> > > - HDMI port
> > > - S/PDIF port
> > > - 5V/2A DC power supply
> > > - Wi-Fi/BT via Fn-Link 6222B-SRB (RTL8222BS)
> >
> > Please dts sync commit details here.
> >
> > >
> > > Signed-off-by: Clément Péron
> > > ---
> > > arch/arm/dts/Makefile | 1 +
> > > arch/arm/dts/sun50i-h6-beelink-gs1.dts | 184 +
> >
> > Seems like this has part of required nodes, sync the complete dts.
>
> Ok so you want to add the complete dts from linux.
>
> I think only IP used in U-boot are needed.
>
> I will do that in v3
>
> >
> > > configs/beelink_gs1_defconfig | 15 ++
> >
> > Add entry on board/sunxi/MAINTAINERS
>
> Ok
>
> >
> > > 3 files changed, 200 insertions(+)
> > > create mode 100644 arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > > create mode 100644 configs/beelink_gs1_defconfig
> > >
> > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > index 86a01c2c70..61e7156284 100644
> > > --- a/arch/arm/dts/Makefile
> > > +++ b/arch/arm/dts/Makefile
> > > @@ -467,6 +467,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
> > > sun50i-h5-orangepi-prime.dtb \
> > > sun50i-h5-orangepi-zero-plus2.dtb
> > > dtb-$(CONFIG_MACH_SUN50I_H6) += \
> > > + sun50i-h6-beelink-gs1.dtb \
> > > sun50i-h6-orangepi-lite2.dtb \
> > > sun50i-h6-orangepi-one-plus.dtb \
> > > sun50i-h6-pine-h64.dtb
> > > diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > > b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > > new file mode 100644
> > > index 00..54b0882bed
> > > --- /dev/null
> > > +++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > > @@ -0,0 +1,184 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > +/*
> > > + * Copyright (C) 2019 Clément Péron
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "sun50i-h6.dtsi"
> > > +
> > > +#include
> > > +
> > > +/ {
> > > + model = "Beelink GS1";
> > > + compatible = "azw,beelink-gs1", "allwinner,sun50i-h6";
> > > +
> > > + aliases {
> > > + serial0 =
> > > + };
> > > +
> > > + chosen {
> > > + stdout-path = "serial0:115200n8";
> > > + };
> > > +
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + power {
> > > + label = "beelink:white:power";
> > > + gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> > > + default-state = "on";
> > > + };
> > > + };
> > > +
> > > + reg_vcc5v: vcc5v {
> > > + /* board wide 5V supply directly from the DC jack */
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vcc-5v";
> > > + regulator-min-microvolt = <500>;
> > > + regulator-max-microvolt = <500>;
> > > + regulator-always-on;
> > > + };
> > > +};
> > > +
> > > + {
> > > + vmmc-supply = <_cldo1>;
> > > + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> > > + bus-width = <4>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + vmmc-supply = <_cldo1>;
> > > + vqmmc-supply = <_bldo2>;
> > > + non-removable;
> > > + cap-mmc-hw-reset;
> > > + bus-width = <8>;
> > > + status = "okay";
> > > +};
> > > +
> > > +_i2c {
> > > + status = "okay";
> > > +
> > > + axp805: pmic@36 {
> > > + compatible = "x-powers,axp805", "x-powers,axp806";
> > > + reg = <0x36>;
> > > + interrupt-parent = <_intc>;
> > > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <1>;
> > > + x-powers,self-working-mode;
> > > + vina-supply = <_vcc5v>;
> > > + vinb-supply = <_vcc5v>;
> > > + vinc-supply = <_vcc5v>;
> > > + vind-supply = <_vcc5v>;
> > > + vine-supply = <_vcc5v>;
> > > + aldoin-supply = <_vcc5v>;
> > > + bldoin-supply = <_vcc5v>;
> > > + cldoin-supply = <_vcc5v>;
> > > +
> > > + regulators {
> > > + reg_aldo1: aldo1 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <330>;
> > > + regulator-max-microvolt = <330>;
> > > + regulator-name = "vcc-pl";
> > > +
[U-Boot] [PATCH] imx: add lowlevel init for ARM64
Sometimes we met SERROR, but only to catch it when Linux boots up. Let's enable catching in U-Boot to catch it ealier and ease debug. Signed-off-by: Peng Fan --- arch/arm/mach-imx/Makefile | 2 +- arch/arm/mach-imx/lowlevel.S | 22 ++ 2 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-imx/lowlevel.S diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index c3ed62aed6..37675d0558 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -204,7 +204,7 @@ endif targets += $(addprefix ../../../,SPL spl/u-boot-spl.cfgout u-boot-dtb.cfgout u-boot.cfgout u-boot.uim spl/u-boot-nand-spl.imx) -obj-$(CONFIG_ARM64) += sip.o +obj-$(CONFIG_ARM64) += lowlevel.o sip.o obj-$(CONFIG_MX5) += mx5/ obj-$(CONFIG_MX6) += mx6/ diff --git a/arch/arm/mach-imx/lowlevel.S b/arch/arm/mach-imx/lowlevel.S new file mode 100644 index 00..158fdb7d87 --- /dev/null +++ b/arch/arm/mach-imx/lowlevel.S @@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2019 NXP + */ + +#include + +ENTRY(lowlevel_init) + mrs x0, CurrentEL + cmp x0, #8 + b.eq1f + ret +1: + msr daifclr, #4 + + /* set HCR_EL2.AMO to catch SERROR */ + mrs x0, hcr_el2 + orr x0, x0, #0x20 + msr hcr_el2, x0 + isb + ret +ENDPROC(lowlevel_init) -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: fec_mxc: not access reserved register on i.MX8
We should not access reserved register on i.MX8, otherwise met SERROR
Signed-off-by: Peng Fan
---
drivers/net/fec_mxc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 84f010d805..097bbd090f 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -604,7 +604,7 @@ static int fec_init(struct eth_device *dev, bd_t *bd)
writel(0x, >eth->gaddr2);
/* Do not access reserved register */
- if (!is_mx6ul() && !is_mx6ull() && !is_imx8m()) {
+ if (!is_mx6ul() && !is_mx6ull() && !is_imx8() && !is_imx8m()) {
/* clear MIB RAM */
for (i = mib_ptr; i <= mib_ptr + 0xfc; i += 4)
writel(0, i);
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5] board/fsl/lx2160a: Fix MC firmware loading during SD boot
> -Original Message- > From: Prabhakar Kushwaha > Sent: Wednesday, 27 March, 2019 11:50 AM > To: Pankaj Bansal ; Meenakshi Aggarwal > ; Priyanka Jain > Cc: u-boot@lists.denx.de > Subject: RE: [PATCH v5] board/fsl/lx2160a: Fix MC firmware loading during SD > boot > > > > -Original Message- > > From: Pankaj Bansal > > Sent: Monday, March 25, 2019 5:28 PM > > To: Meenakshi Aggarwal ; Priyanka Jain > > ; Prabhakar Kushwaha > > > > Cc: u-boot@lists.denx.de; Pankaj Bansal > > Subject: [PATCH v5] board/fsl/lx2160a: Fix MC firmware loading during > > SD boot > > > > during SD boot, following error comes: > > MMC read: dev # 0, block # 20480, count 2048 ... 2048 blocks read: > > OK > > > > MMC read: dev # 0, block # 28672, count 2048 ... 2048 blocks read: OK > > fsl-mc: ERR: Bad firmware image (bad FIT header) > > Hit any key to stop autoboot: 0 > > > > it's occurring because mc 10.14.3 file size is 1064880, which means > > 0x820 SD blocks which is more than 0x800 blocks (1MB). This results in > > DPC loading address 0x8010 overlapping with MC loading address > 0x8000. > > > > so, update the MC/dpl/dpc addresses as per their addresses in SD card. > > Assuming that SD card block size is 512 bytes and 0x0 block in SD card > > would get loaded at 0x8000 (DDR base address), this gives > > following addresses for various binaries: > > > > Binary | SD block | DDR offset > > -- > > MC | 0x5000 | 0x80a0 > > DPL| 0x6800 | 0x80d0 > > DPC| 0x7000 | 0x80e0 > > > > This info should be part of README present in board folder. > No need to add in commit message. It is. Please check https://elixir.bootlin.com/u-boot/latest/source/board/freescale/lx2160a/README#L68 > > --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Remove whitelist entry for CONFIG_CRC32
Hello Chris, Am 13.04.2019 um 11:13 schrieb Chris Packham: There are no longer any references to this in the code so this can be removed. Signed-off-by: Chris Packham --- scripts/config_whitelist.txt | 1 - 1 file changed, 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] Remove #define CONFIG_CRC32
Hello Chris, Am 13.04.2019 um 11:13 schrieb Chris Packham: There is no check for CONFIG_CRC32 so the #define in image.h does nothing. Remove it. Reported-by: Robert P. J. Day Signed-off-by: Chris Packham --- include/image.h | 1 - 1 file changed, 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mtd: ubi: Remove select for non existent option
Hello Chris, Am 13.04.2019 um 11:13 schrieb Chris Packham: There is no 'config CRC32' remove the select that was attempting to use it. Reported-by: Robert P. J. Day Signed-off-by: Chris Packham --- drivers/mtd/ubi/Kconfig | 1 - 1 file changed, 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] cmd: ubifs: Remove select for non-existent option
Hello Chris, Am 13.04.2019 um 11:13 schrieb Chris Packham: There is no 'config CRC32', remove the select that was attempting to use it. Reported-by: Robert P. J. Day Signed-off-by: Chris Packham --- cmd/Kconfig | 2 -- 1 file changed, 2 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v12 0/9] Add support for loading FPGA bitstream
On Tue, 2019-03-19 at 16:50 +0800, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > This version mainly resolved comments from Dinh in [v11]. > > This series is working on top of u-boot.git http://git.denx.de/u-boot > .git > > These patches are required before applying this series of patches > 1. [U-Boot,v4] misc: fs_loader: Add support for initializing block > device > https://patchwork.ozlabs.org/project/uboot/list/?series=89282 (done > review) > > 2. [U-Boot] fpga: Replace char * with const char * for filename > https://patchwork.ozlabs.org/patch/1042665/ (done review) > > 3. [U-Boot] misc: fs_loader: Replace label with DT phandle > https://patchwork.ozlabs.org/patch/1051782/ (under review) > > [v11]: https://www.mail-archive.com/u-boot@lists.denx.de/msg318174.ht > ml > [v10]: https://www.mail-archive.com/u-boot@lists.denx.de/msg318167.ht > ml > [v9]: https://www.mail-archive.com/u-boot@lists.denx.de/msg316086.htm > l > [v8]: https://www.mail-archive.com/u-boot@lists.denx.de/msg316086.htm > l > [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg314511.htm > l > > Tien Fong Chee (9): > ARM: socfpga: Description on FPGA bitstream type and file name for > Arria 10 > ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK > ARM: socfpga: Cleaning up and ensuring consistent format messages > in > driver > ARM: socfpga: Moving the watchdog reset to the for-loop status > polling > ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading > ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK > spl : socfpga: Implement fpga bitstream loading with socfpga loadfs > ARM: socfpga: Synchronize the configuration for A10 SoCDK > ARM: socfpga: Increase Malloc pool size to support FAT filesystem > in > SPL > > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 + > .../include/mach/fpga_manager_arria10.h| 40 +- > arch/arm/mach-socfpga/spl_a10.c| 31 +- > board/altera/arria10-socdk/fit_spl_fpga.its| 38 ++ > configs/socfpga_arria10_defconfig | 22 +- > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 26 +- > drivers/fpga/socfpga_arria10.c | 514 > - > include/configs/socfpga_common.h | 4 +- > include/image.h| 4 + > 9 files changed, 664 insertions(+), 32 deletions(-) > create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its > Any comment about this series of patches? Thanks. Regards, TF. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: btrfs: fix btrfs_search_tree invalid results
Hi Pierre
On Mon, 15 Apr 2019 03:30:32 +0200
Pierre Bourdon wrote:
> btrfs_search_tree should return the first item in the tree that is
> greater or equal to the searched item.
>
> The search algorithm did not properly handle the edge case where the
> searched item is higher than the last item of the node but lower than
> the first item of the next node. Instead of properly returning the first
> item of the next node, it was returning an invalid path pointer
> (pointing to a non-existent item after the last item of the node + 1).
>
> This fixes two issues in the btrfs driver:
> - Looking for a ROOT_ITEM could fail if it was the first item of its
> leaf node.
> - Iterating through DIR_INDEX entries (for readdir) could fail if the
> first DIR_INDEX entry was the first item of a leaf node.
>
> Signed-off-by: Pierre Bourdon
> Cc: Marek Behun
> ---
> fs/btrfs/ctree.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
> index d248d79932..55246ea0fc 100644
> --- a/fs/btrfs/ctree.c
> +++ b/fs/btrfs/ctree.c
> @@ -187,8 +187,13 @@ int btrfs_search_tree(const struct btrfs_root *root,
> struct btrfs_key *key,
>
> if (lvl)
> logical = buf->node.ptrs[slot].blockptr;
> - else
> + else {
> + /* cur leaf max < searched value < next leaf min */
> + if (slot >= buf->header.nritems)
> + if (btrfs_next_slot(p) < 0)
> + goto err;
> break;
> + }
Hi Pierre, if you are adding { } braces to else, please add them to the
if also. Also comment that you are correcting for invalid slot value.
if (lvl) {
logical = buf->node.ptrs[slot].blockptr;
} else {
/*
* Slot can have invalid value if
* current leaf max < searched value < next leaf min.
* Jump to next in this case.
*/
if (slot >= buf->header.nritems)
if (btrfs_next_slot(p) < 0)
goto err;
break;
}
Otherwise thanks, I encountered some problems a once or twice but
didn't have time to investigate.
Marek
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] delete Kbuild "select" of long-dead SPL_DISABLE_OF_CONTROL
On Sun, Apr 14, 2019 at 7:21 PM Robert P. J. Day wrote: > > > From way back in 2015: > > commit dffb86e468c8e02ba77283989aefef214d904dc5 > Author: Masahiro Yamada > Date: Wed Aug 12 07:31:54 2015 +0900 > > of: flip CONFIG_SPL_DISABLE_OF_CONTROL into CONFIG_SPL_OF_CONTROL > > As we discussed a couple of times, negative CONFIG options make our > life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ... > and here is another one. > > Now, there are three boards enabling OF_CONTROL on SPL: > - socfpga_arria5_defconfig > - socfpga_cyclone5_defconfig > - socfpga_socrates_defconfig > > This commit adds CONFIG_SPL_OF_CONTROL for them and deletes > CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert > the logic. > > Signed-off-by: Masahiro Yamada > Reviewed-by: Tom Rini > Reviewed-by: Simon Glass Thanks for catching this. Reviewed-by: Masahiro Yamada > --- > > AFAICT, simple deletion should be sufficient but i'm willing to be > convinced otherwise. > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index 3807770362..14347e7c7d 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -116,7 +116,6 @@ config TARGET_SNOW > config TARGET_SPRING > bool "Spring board" > select OF_CONTROL > - select SPL_DISABLE_OF_CONTROL > select SUPPORT_SPL > > config TARGET_SMDK5420 > @@ -150,7 +149,6 @@ config TARGET_ESPRESSO7420 > select OF_CONTROL > select PINCTRL > select PINCTRL_EXYNOS7420 > - select SPL_DISABLE_OF_CONTROL > select SUPPORT_SPL > > endchoice > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
On 4/15/2019 6:35 AM, Tom Rini wrote: On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote: On 4/13/2019 6:32 PM, Tom Rini wrote: On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote: The series adds the support for hardware leveling. This needs the kernel to be patched with hardware leveling support and the kernel support is already in linux-next: https://patchwork.kernel.org/project/linux-omap/list/?series=100273 Match recommended values from EMIF Tools app note: http://www.ti.com/lit/an/sprac70/sprac70.pdf What happens if you boot an old kernel with this series applied? I'm a bit worried about applying something that breaks existing kernels, thanks! Hi Tom, Deep Sleep 0 feature will fail as the corresponding hardware leveling patches will not be present. So to be clear, some new functionality will not work, but there is no functional regression? Okay i got your concern. Deep sleep 0 is currently working with software leveling that will stop working with this patch series(hardware leveling) applied on older kernels. EMIF tools application note recommends hardware leveling over what existed previously. Hence i posted this series. Older kernels with this patch series Deep sleep 0 feature will regress. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fs: btrfs: fix btrfs_search_tree invalid results
btrfs_search_tree should return the first item in the tree that is
greater or equal to the searched item.
The search algorithm did not properly handle the edge case where the
searched item is higher than the last item of the node but lower than
the first item of the next node. Instead of properly returning the first
item of the next node, it was returning an invalid path pointer
(pointing to a non-existent item after the last item of the node + 1).
This fixes two issues in the btrfs driver:
- Looking for a ROOT_ITEM could fail if it was the first item of its
leaf node.
- Iterating through DIR_INDEX entries (for readdir) could fail if the
first DIR_INDEX entry was the first item of a leaf node.
Signed-off-by: Pierre Bourdon
Cc: Marek Behun
---
fs/btrfs/ctree.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index d248d79932..55246ea0fc 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -187,8 +187,13 @@ int btrfs_search_tree(const struct btrfs_root *root,
struct btrfs_key *key,
if (lvl)
logical = buf->node.ptrs[slot].blockptr;
- else
+ else {
+ /* cur leaf max < searched value < next leaf min */
+ if (slot >= buf->header.nritems)
+ if (btrfs_next_slot(p) < 0)
+ goto err;
break;
+ }
}
return 0;
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: btrfs: fix false negatives in ROOT_ITEM search
On Sun, Apr 14, 2019 at 12:05 AM Pierre Bourdon wrote: > A more practical example in case the explanation isn't clear: > > root tree > node 122216448 level 1 items 6 free 115 generation 12246 owner ROOT_TREE > fs uuid b516974e-a94e-469c-a9ff-d237ce96b03b > chunk uuid ecfa1e4e-8832-49c1-bb0c-2f08b95586a0 > key (EXTENT_TREE ROOT_ITEM 0) block 122810368 gen 12246 > key (ROOT_TREE_DIR INODE_REF 6) block 122339328 gen 12246 > key (344 ROOT_ITEM 9422) block 209317888 gen 12115 > key (344 ROOT_BACKREF 5) block 226222080 gen 12126 > key (368 ROOT_ITEM 11665) block 114966528 gen 12127 > key (375 ROOT_ITEM 12127) block 122949632 gen 12246 > > If you look for (375 ROOT_ITEM) then using (375 ROOT_ITEM 0) as the > search key will end up walking to block 114966528 (because (375 > ROOT_ITEM 0) < (375 ROOT_ITEM 12127)). Using instead (375 ROOT_ITEM > -1) will go to the right leaf, return the first item after (375 > ROOT_ITEM 12127), and we can then walk back one slot to get the item > we wanted. So turns out there's a very similar bug when iterating DIR_INDEX entries -- but that one isn't using btrfs_search_tree_key_type. It's doing its own thing with offset = 0 to enumerate multiple items of the same oid/type. Looking back at this, I think there's a much better way to fix both issues. Currently, btrfs_search_tree will return an invalid path if it's asked to look for an item between end of leaf N and beginning of leaf N+1. Invalid, as in, accessing the element at this path reads past the end of an array... This seems like a very broken behavior given that callers have no way of knowing the path is invalid without dereferencing it. Instead, btrfs_search_tree should be fixed so that it always returns either: 1. The first element >= searched element. 2. An error if no such element exists. This can be done with a fairly trivial change to btrfs_search_tree: if we're about to return something that's past the end of the leaf (slot >= nritems), call btrfs_next_slot on the path. If btrfs_next_slot works return that, otherwise return an error. I'll send another patch which implements that instead. I've verified it fixes both the root lookup issue I was originally looking for + the DIR_INDEX issue as well. Please disregard the patch I originally sent. -- Pierre Bourdon Software Engineer @ Zürich, Switzerland https://delroth.net/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote: > > > On 4/13/2019 6:32 PM, Tom Rini wrote: > >On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote: > > > >>The series adds the support for hardware leveling. This needs the > >>kernel to be patched with hardware leveling support and the > >>kernel support is already in linux-next: > >> > >>https://patchwork.kernel.org/project/linux-omap/list/?series=100273 > >> > >>Match recommended values from EMIF Tools app note: > >>http://www.ti.com/lit/an/sprac70/sprac70.pdf > > > >What happens if you boot an old kernel with this series applied? I'm a > >bit worried about applying something that breaks existing kernels, > >thanks! > > Hi Tom, > > Deep Sleep 0 feature will fail as the corresponding hardware leveling > patches will not be present. So to be clear, some new functionality will not work, but there is no functional regression? -- 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 0/6] board: ti: am43xx: Enable hardware leveling
On 4/13/2019 6:32 PM, Tom Rini wrote: On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote: The series adds the support for hardware leveling. This needs the kernel to be patched with hardware leveling support and the kernel support is already in linux-next: https://patchwork.kernel.org/project/linux-omap/list/?series=100273 Match recommended values from EMIF Tools app note: http://www.ti.com/lit/an/sprac70/sprac70.pdf What happens if you boot an old kernel with this series applied? I'm a bit worried about applying something that breaks existing kernels, thanks! Hi Tom, Deep Sleep 0 feature will fail as the corresponding hardware leveling patches will not be present. Regards, Keerthy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address
On Sun, Apr 14, 2019 at 10:13:15PM +0200, Eugeniu Rosca wrote:
> Hi Simon,
> CC: Tom, Yamada-san, Jiri, Stephen,
>
> On Sat, Mar 30, 2019 at 03:19:23PM -0600, Simon Glass wrote:
> > Hi Eugeniu,
> >
> > On Mon, 25 Mar 2019 at 04:44, Eugeniu Rosca wrote:
> > >
> > > Hello Simon,
> > >
> > > On Sun, Mar 10, 2019 at 03:51:47PM -0600, Simon Glass wrote:
> > > [..]
> > > > Reviewed-by: Simon Glass
> > >
> > > Can this fix go to u-boot-dm or is more review required?
> > >
> >
> > Yes it looks like it is in my queue.
> >
> > Regards,
> > Simon
>
> First, many thanks for pushing the fix to u-boot-dm.
>
> Second, I would like to (repeatedly [0]) point out a pretty rare
> corruption of patch metadata, which places the 'Reviewed-by:'
> (and actually any other "*-by: ") signature on top of the '='
> line if the latter is present in commit description (see [1]).
>
> As Yamada-san pointed out in [0], this is presumably caused by a
> patchwork bug and after some grepping through the patchwork git
> history, it looks like the issue is already fixed in patchwork master
> thanks to Jiri and Stephen via commit [2].
>
> My guess is that the U-Boot patchwork version might not be containing
> this recent fix, hence still showcasing the wrong behavior?
>
> FWIW, at least below U-Boot commits exhibit the same inconsistency:
>
> u-boot $> for c in $(git log --format=%h --grep "^==="); \
> do \
> git log --format=%B -1 $c | grep -B 2 "^===" | \
> grep -q "by:.*@" && git --no-pager log --oneline -1 $c; \
> done
>
> 0506620f4f49 sata: sata_mv: Add DM support to enable CONFIG_BLK usage
> 9bfacf249b10 core: ofnode: Fix ASAN-reported stack-buffer-overflow in
> of_get_address
> e1904f4530a3 common: avb_verify: Fix division by zero in mmc_byte_io()
> e91610da7c8a kconfig: re-sync with Linux 4.17-rc4
> e810565e23cd i.MX6DL: mamoj: Add PFUZE100 support
> dda9892171c3 i.MX6DL: mamoj: Add I2C support
> a0b0ff0ae643 arm: dra7xx: Fix Linux boot from eMMC
> f6d245b8c56c arm: am57xx: Fix Linux boot from eMMC
> 67ff9e11f397 wandboard: move environment partition farther from u-boot.img
>
> [0] https://marc.info/?l=u-boot=152643616902958=2
> [1] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=9bfacf249b10
> [2] https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932
> ("parser: fix parsing of patches with headings")
Adding in Jeremy since we just use the ozlabs patchwork, 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 3/8] video/console: Implement relative cursor movement ANSI handling
On 14/04/2019 13:54, Anatolij Gustschin wrote: > Hi André, > > On Sat, 13 Apr 2019 22:40:03 +0100 > André Przywara andre.przyw...@arm.com wrote: > ... >>> I've dropped all applied patches of this series now, some of them >>> introduced dm video_ansi test error [1]. Please fix. Thanks! >> >> Hmh, good one. Didn't find an easy way to get to the bottom of this >> within the ut test system, so I copied the ANSI sequences out and >> replayed them with a custom command, inspecting the (sandbox) screen >> manually. Is there a canonical way to trace down those issues? > > You can build sandbox defconfig an run U-Boot with "--show_lcd" > option, then run the "ut dm video_ansi" command to inspect the > rendered characters and colors, e.g.: > > $ make sandbox_defconfig > $ make > $ ./u-boot -d arch/sandbox/dts/test.dtb -l Ah, I did everything exactly as you, except I was using "-D" (sandbox64.dtb), not test.dtb. With sandbox64.dtb I could run the test and see the test summary report, but didn't see the actual graphical output. > U-Boot 2019.04-00326-g7b64a70a3a (Apr 14 2019 - 14:37:44 +0200) > > Model: sandbox > DRAM: 128 MiB > MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD) > In:serial > Out: vidconsole > Err: vidconsole > Model: sandbox > SCSI: > Net: eth0: eth@10002000, eth5: eth@10003000, eth3: sbe5, eth1: eth@10004000 > Hit any key to stop autoboot: 0 > => ut dm video_ansi > Test: dm_test_video_ansi: video.c > Failures: 0 > > In the "U-Boot" window you will see the output of the video_ansi test. > > Without your fix for masking bit 3 in the bg index, the high-intensity > background colors will be used, you will see brighter BG colors. The test > expects results for standard background colors (indexes 0-7). Yes, that's what I figured after sending the same escape sequences as the test from a hacked "cls" command. But it took me actually a screenshot to spot the difference ;-) >> Anyway, the fix for patch 2/8 is rather simple (see below), do you want >> to fix this up in your tree? Or shall I sent a v2? > > Thanks! I've merged your fix for patch 2/8, no need to resend. Build- > testing now. Great, thanks a lot! Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] sunxi: Add support for Olimex A64-Teres-I board
Quoting Jagan Teki (2019-04-14 19:36:15) > On Sun, Apr 14, 2019 at 10:16 PM Jonas Smedegaard wrote: > > > > Olimex Teres-I is a laptop DIY kit, and A64-Teres-I is its mainboard. > > https://linux-sunxi.org/Olimex_Teres-A64 > > > > This patch enables support for the A64-Teres-I board to u-boot, > > including enabling screen backlight (lacking from Linux device-tree). > > > > sun50i-a64-teres-i.dts is copied verbatim from Linux 5.0. > > Cosmetic warnings regarding whitespace and placement of SPDX notice for > > this file was ignored. > > Add the commit id details from which commit it synced from. You mean mention explicitly that the git tag for Linux 5.0 is "v5.0"? Or mention explicitly the hash corresponding to that tag? Or mention the hash for the last commit affecting that particular file? Or mention a URL pointing to the file, e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts?h=v5.0 ? > > config and .dtsi file are adapted from pinebook files. > > > > Author: Vasily Khoruzhick > > Didn't find this tag before, may be you can add details in commit > message itself. Ok, will then simply delete that: Already mentioned in file headers. > > Tested-by: Jonas Smedegaard > > Signed-off-by: Jonas Smedegaard > > --- > > > > arch/arm/dts/Makefile | 3 +- > > arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi | 41 +++ > > arch/arm/dts/sun50i-a64-teres-i.dts | 270 > > configs/teres_i_defconfig | 21 ++ > > Maintainer entry? Will add myself and Icenowy (who've worked on this in the past and have agreed to help look after this). Thanks for the feedback, Jagan, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] sunxi: Add support for Olimex A64-Teres-I board
Olimex Teres-I is a laptop DIY kit, and A64-Teres-I is its mainboard.
https://linux-sunxi.org/Olimex_Teres-A64
This patch enables support for the A64-Teres-I board to u-boot,
including enabling screen backlight (lacking from Linux device-tree).
sun50i-a64-teres-i.dts is copied verbatim from Linux 5.0.
Cosmetic warnings regarding whitespace and placement of SPDX notice for
this file was ignored.
config and .dtsi file are adapted from pinebook files.
Author: Vasily Khoruzhick
Tested-by: Jonas Smedegaard
Signed-off-by: Jonas Smedegaard
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi | 41 +++
arch/arm/dts/sun50i-a64-teres-i.dts | 270
configs/teres_i_defconfig | 21 ++
4 files changed, 334 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi
create mode 100644 arch/arm/dts/sun50i-a64-teres-i.dts
create mode 100644 configs/teres_i_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8167cdb4e8..a12ed81f49 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -483,7 +483,8 @@ dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-pine64-plus.dtb \
sun50i-a64-pine64.dtb \
sun50i-a64-pinebook.dtb \
- sun50i-a64-sopine-baseboard.dtb
+ sun50i-a64-sopine-baseboard.dtb \
+ sun50i-a64-teres-i.dtb
dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
sun9i-a80-cubieboard4.dtb \
diff --git a/arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi
b/arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi
new file mode 100644
index 00..1a64b7d09c
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Vasily Khoruzhick
+ *
+ */
+
+#include "sunxi-u-boot.dtsi"
+
+/ {
+ vdd_bl: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "bl-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
+ enable-active-high;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 0>;
+ brightness-levels = <0 5 10 15 20 30 40 55 70 85 100>;
+ default-brightness-level = <2>;
+ enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <_bl>;
+ };
+};
+
+/* The ANX6345 eDP-bridge is on i2c */
+ {
+ anx6345: edp-bridge@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ status = "okay";
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/sun50i-a64-teres-i.dts
b/arch/arm/dts/sun50i-a64-teres-i.dts
new file mode 100644
index 00..c455b24dd0
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-teres-i.dts
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) Harald Geyer
+ * based on sun50i-a64-olinuxino.dts by Jagan Teki
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR MIT)
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "Olimex A64 Teres-I";
+ compatible = "olimex,a64-teres-i", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+
+ framebuffer-lcd {
+ eDP25-supply = <_dldo2>;
+ eDP12-supply = <_dldo3>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ lid-switch {
+ label = "Lid Switch";
+ gpios = <_pio 0 8 GPIO_ACTIVE_LOW>; /* PL8 */
+ linux,input-type = ;
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ capslock {
+ label = "teres-i:green:capslock";
+ gpios = < 2 7 GPIO_ACTIVE_HIGH>; /* PC7 */
+ };
+
+ numlock {
+ label = "teres-i:green:numlock";
+ gpios = < 2 4 GPIO_ACTIVE_HIGH>; /* PC4 */
+ };
+ };
+
+ reg_usb1_vbus: usb1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb1-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = <_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
+ status = "okay";
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+
Re: [U-Boot] [PATCH v2 2/3] arm: dts: h6: Add Beelink GS1 initial support
Hi,
On Sun, 14 Apr 2019 at 19:29, Jagan Teki wrote:
>
> On Fri, Apr 12, 2019 at 7:45 PM Clément Péron wrote:
> >
> > Beelink GS1 is an Allwinner H6 based TV box,
> > which support:
> > - Allwinner H6 Quad-core 64-bit ARM Cortex-A53
> > - GPU Mali-T720
> > - 2GB LPDDR3 RAM
> > - 16GB eMMC
> > - AXP805 PMIC
> > - 1Gbps GMAC via RTL8211E
> > - USB 2.0 and 3.0 Host
> > - HDMI port
> > - S/PDIF port
> > - 5V/2A DC power supply
> > - Wi-Fi/BT via Fn-Link 6222B-SRB (RTL8222BS)
>
> Please dts sync commit details here.
>
> >
> > Signed-off-by: Clément Péron
> > ---
> > arch/arm/dts/Makefile | 1 +
> > arch/arm/dts/sun50i-h6-beelink-gs1.dts | 184 +
>
> Seems like this has part of required nodes, sync the complete dts.
Ok so you want to add the complete dts from linux.
I think only IP used in U-boot are needed.
I will do that in v3
>
> > configs/beelink_gs1_defconfig | 15 ++
>
> Add entry on board/sunxi/MAINTAINERS
Ok
>
> > 3 files changed, 200 insertions(+)
> > create mode 100644 arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > create mode 100644 configs/beelink_gs1_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 86a01c2c70..61e7156284 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -467,6 +467,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
> > sun50i-h5-orangepi-prime.dtb \
> > sun50i-h5-orangepi-zero-plus2.dtb
> > dtb-$(CONFIG_MACH_SUN50I_H6) += \
> > + sun50i-h6-beelink-gs1.dtb \
> > sun50i-h6-orangepi-lite2.dtb \
> > sun50i-h6-orangepi-one-plus.dtb \
> > sun50i-h6-pine-h64.dtb
> > diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > new file mode 100644
> > index 00..54b0882bed
> > --- /dev/null
> > +++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > @@ -0,0 +1,184 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2019 Clément Péron
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h6.dtsi"
> > +
> > +#include
> > +
> > +/ {
> > + model = "Beelink GS1";
> > + compatible = "azw,beelink-gs1", "allwinner,sun50i-h6";
> > +
> > + aliases {
> > + serial0 =
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + power {
> > + label = "beelink:white:power";
> > + gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> > + default-state = "on";
> > + };
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the DC jack */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > + {
> > + vmmc-supply = <_cldo1>;
> > + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + vmmc-supply = <_cldo1>;
> > + vqmmc-supply = <_bldo2>;
> > + non-removable;
> > + cap-mmc-hw-reset;
> > + bus-width = <8>;
> > + status = "okay";
> > +};
> > +
> > +_i2c {
> > + status = "okay";
> > +
> > + axp805: pmic@36 {
> > + compatible = "x-powers,axp805", "x-powers,axp806";
> > + reg = <0x36>;
> > + interrupt-parent = <_intc>;
> > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + x-powers,self-working-mode;
> > + vina-supply = <_vcc5v>;
> > + vinb-supply = <_vcc5v>;
> > + vinc-supply = <_vcc5v>;
> > + vind-supply = <_vcc5v>;
> > + vine-supply = <_vcc5v>;
> > + aldoin-supply = <_vcc5v>;
> > + bldoin-supply = <_vcc5v>;
> > + cldoin-supply = <_vcc5v>;
> > +
> > + regulators {
> > + reg_aldo1: aldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> > + regulator-name = "vcc-pl";
> > + };
> > +
> > + reg_aldo2: aldo2 {
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> > + regulator-name = "vcc-ac200";
> > + regulator-enable-ramp-delay = <10>;
> > +
Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address
Hi Simon,
CC: Tom, Yamada-san, Jiri, Stephen,
On Sat, Mar 30, 2019 at 03:19:23PM -0600, Simon Glass wrote:
> Hi Eugeniu,
>
> On Mon, 25 Mar 2019 at 04:44, Eugeniu Rosca wrote:
> >
> > Hello Simon,
> >
> > On Sun, Mar 10, 2019 at 03:51:47PM -0600, Simon Glass wrote:
> > [..]
> > > Reviewed-by: Simon Glass
> >
> > Can this fix go to u-boot-dm or is more review required?
> >
>
> Yes it looks like it is in my queue.
>
> Regards,
> Simon
First, many thanks for pushing the fix to u-boot-dm.
Second, I would like to (repeatedly [0]) point out a pretty rare
corruption of patch metadata, which places the 'Reviewed-by:'
(and actually any other "*-by: ") signature on top of the '='
line if the latter is present in commit description (see [1]).
As Yamada-san pointed out in [0], this is presumably caused by a
patchwork bug and after some grepping through the patchwork git
history, it looks like the issue is already fixed in patchwork master
thanks to Jiri and Stephen via commit [2].
My guess is that the U-Boot patchwork version might not be containing
this recent fix, hence still showcasing the wrong behavior?
FWIW, at least below U-Boot commits exhibit the same inconsistency:
u-boot $> for c in $(git log --format=%h --grep "^==="); \
do \
git log --format=%B -1 $c | grep -B 2 "^===" | \
grep -q "by:.*@" && git --no-pager log --oneline -1 $c; \
done
0506620f4f49 sata: sata_mv: Add DM support to enable CONFIG_BLK usage
9bfacf249b10 core: ofnode: Fix ASAN-reported stack-buffer-overflow in
of_get_address
e1904f4530a3 common: avb_verify: Fix division by zero in mmc_byte_io()
e91610da7c8a kconfig: re-sync with Linux 4.17-rc4
e810565e23cd i.MX6DL: mamoj: Add PFUZE100 support
dda9892171c3 i.MX6DL: mamoj: Add I2C support
a0b0ff0ae643 arm: dra7xx: Fix Linux boot from eMMC
f6d245b8c56c arm: am57xx: Fix Linux boot from eMMC
67ff9e11f397 wandboard: move environment partition farther from u-boot.img
[0] https://marc.info/?l=u-boot=152643616902958=2
[1] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=9bfacf249b10
[2] https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932
("parser: fix parsing of patches with headings")
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request for UEFI sub-system for v2019.07-rc1 (2)
The following changes since commit 40a9546c7b6217a78a3a010a0142529a837e46b6: Merge branch '2019-04-11-ti-master-imports' (2019-04-12 12:22:43 -0400) are available in the Git repository at: https://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc1-2 for you to fetch changes up to 8688b753916bfdde3c2911f14d4489c36e705db7: efi_selftest: expect boot services data for fdt (2019-04-12 22:09:09 +0200) Travis CI showed no errors: https://travis-ci.org/xypron2/u-boot/builds/519424329 Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 Pull request for UEFI sub-system for v2019.07-rc1 (2) In the aarch64 crash dump information about the loaded EFI images is added. In README.uefi the development target is for the UEFI subsystem is described as "Embedded Base Boot Requirements (EBBR) Specification" compliance. Several bug fixes are supplied. Heinrich Schuchardt (12): efi_loader: assign HII protocols to root node efi_loader: enable HII protocols by default efi_loader: remove stray #define LOG_CATEGORY LOGL_ERR efi_loader: move efi_save_gd() call to board_r.c arm: print information about loaded UEFI images efi_loader: the development target should be the EBBR efi_loader: fix setting PlatformLang efi_loader: update virtual address in efi_mem_carve_out efi_selftest: physical and virtual addresses must match efi_loader: export efi_install_multiple_protocol_interfaces efi_loader: simplify protocol installation efi_selftest: expect boot services data for fdt Ilias Apalodimas (1): Change FDT memory type from runtime data to boot services data Patrick Delaunay (1): efi_loader: add protection for block_dev Patrick Wildt (1): efi: fix memory calculation overflow on 32-bit systems arch/arm/lib/interrupts_64.c | 13 ++ cmd/bootefi.c | 4 +- common/board_r.c | 7 doc/README.uefi| 12 -- include/efi.h | 2 +- include/efi_loader.h | 3 ++ lib/efi_driver/efi_uclass.c| 3 -- lib/efi_loader/Kconfig | 17 +--- lib/efi_loader/efi_boottime.c | 22 +- lib/efi_loader/efi_device_path.c | 4 +- lib/efi_loader/efi_memory.c| 2 + lib/efi_loader/efi_root_node.c | 60 --- lib/efi_loader/efi_setup.c | 75 +- lib/efi_selftest/efi_selftest_memory.c | 11 +++-- 14 files changed, 140 insertions(+), 95 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board: tbs2910: Remove CMD_FDT support in defconfig to reduce u-boot size
This fixes the build failure "u-boot.imx exceeds file size limit". Signed-off-by: Soeren Moch --- Cc: Stefano Babic Cc: u-boot@lists.denx.de --- configs/tbs2910_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index 4d755c88c3..8c20c7b4b7 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -15,6 +15,7 @@ CONFIG_BOARD_EARLY_INIT_F=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Matrix U-Boot> " CONFIG_CMD_BOOTZ=y +# CONFIG_CMD_FDT is not set CONFIG_CMD_MEMTEST=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-video
Hi Tom, please pull video updates for v2019.07-rc1. Travis CI: https://travis-ci.org/vdsao/u-boot-video/builds/51990 Thanks, Anatolij The following changes since commit cf5eebeb18f7790d5030eb94f51fca0ebcd6e406: Merge tag 'pull-12apr19' of git://git.denx.de/u-boot-dm (2019-04-13 08:27:35 -0400) are available in the Git repository at: git://git.denx.de/u-boot-video.git tags/video-for-2019.07-rc1 for you to fetch changes up to 7b64a70a3a0113f9cd5356b3260d4740edb03265: sunxi: allow boards to de-select SYS_WHITE_ON_BLACK font scheme (2019-04-14 14:18:48 +0200) - optional backlight PWM polarity config via polarity cell - bug fix for ASCII characters > 127 - ANSI sequence handling extensions (implement clear line, reverse video and relative cursor movement commands) - preparation for doing character set translations - left/right and up/down arrow keys translation to ANSI control sequences for cursor movement to fix selection with an USB keyboard in bootmenu - CONFIG_SYS_WHITE_ON_BLACK font scheme configuration for sunxi boards Andre Przywara (7): video/console: Fix DM_VIDEO font glyph array indexing video/console: Implement reverse video ANSI sequence for DM_VIDEO video/console: Implement relative cursor movement ANSI handling video/console: Implement ANSI clear line command video/console: Factor out actual character output usb: kbd: Properly translate up/down arrow keys sunxi: allow boards to de-select SYS_WHITE_ON_BLACK font scheme Stefan Mavrodiev (1): video: backlight: Parse PWM polarity cell common/usb_kbd.c | 24 - drivers/video/Kconfig | 2 +- drivers/video/console_normal.c| 3 +- drivers/video/console_rotate.c| 7 +-- drivers/video/pwm_backlight.c | 11 drivers/video/vidconsole-uclass.c | 111 -- drivers/video/video-uclass.c | 1 + include/configs/sunxi-common.h| 1 - include/video.h | 2 + 9 files changed, 138 insertions(+), 24 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] sunxi: Add support for Olimex A64-Teres-I board
On Sun, Apr 14, 2019 at 10:16 PM Jonas Smedegaard wrote: > > Olimex Teres-I is a laptop DIY kit, and A64-Teres-I is its mainboard. > https://linux-sunxi.org/Olimex_Teres-A64 > > This patch enables support for the A64-Teres-I board to u-boot, > including enabling screen backlight (lacking from Linux device-tree). > > sun50i-a64-teres-i.dts is copied verbatim from Linux 5.0. > Cosmetic warnings regarding whitespace and placement of SPDX notice for > this file was ignored. Add the commit id details from which commit it synced from. > > config and .dtsi file are adapted from pinebook files. > > Author: Vasily Khoruzhick Didn't find this tag before, may be you can add details in commit message itself. > Tested-by: Jonas Smedegaard > Signed-off-by: Jonas Smedegaard > --- > > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi | 41 +++ > arch/arm/dts/sun50i-a64-teres-i.dts | 270 > configs/teres_i_defconfig | 21 ++ Maintainer entry? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] arm: dts: h6: Add Beelink GS1 initial support
On Fri, Apr 12, 2019 at 7:45 PM Clément Péron wrote:
>
> Beelink GS1 is an Allwinner H6 based TV box,
> which support:
> - Allwinner H6 Quad-core 64-bit ARM Cortex-A53
> - GPU Mali-T720
> - 2GB LPDDR3 RAM
> - 16GB eMMC
> - AXP805 PMIC
> - 1Gbps GMAC via RTL8211E
> - USB 2.0 and 3.0 Host
> - HDMI port
> - S/PDIF port
> - 5V/2A DC power supply
> - Wi-Fi/BT via Fn-Link 6222B-SRB (RTL8222BS)
Please dts sync commit details here.
>
> Signed-off-by: Clément Péron
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/sun50i-h6-beelink-gs1.dts | 184 +
Seems like this has part of required nodes, sync the complete dts.
> configs/beelink_gs1_defconfig | 15 ++
Add entry on board/sunxi/MAINTAINERS
> 3 files changed, 200 insertions(+)
> create mode 100644 arch/arm/dts/sun50i-h6-beelink-gs1.dts
> create mode 100644 configs/beelink_gs1_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 86a01c2c70..61e7156284 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -467,6 +467,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
> sun50i-h5-orangepi-prime.dtb \
> sun50i-h5-orangepi-zero-plus2.dtb
> dtb-$(CONFIG_MACH_SUN50I_H6) += \
> + sun50i-h6-beelink-gs1.dtb \
> sun50i-h6-orangepi-lite2.dtb \
> sun50i-h6-orangepi-one-plus.dtb \
> sun50i-h6-pine-h64.dtb
> diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> new file mode 100644
> index 00..54b0882bed
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2019 Clément Péron
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +
> +#include
> +
> +/ {
> + model = "Beelink GS1";
> + compatible = "azw,beelink-gs1", "allwinner,sun50i-h6";
> +
> + aliases {
> + serial0 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "beelink:white:power";
> + gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> + default-state = "on";
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC jack */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +};
> +
> + {
> + vmmc-supply = <_cldo1>;
> + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> + {
> + vmmc-supply = <_cldo1>;
> + vqmmc-supply = <_bldo2>;
> + non-removable;
> + cap-mmc-hw-reset;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
> +_i2c {
> + status = "okay";
> +
> + axp805: pmic@36 {
> + compatible = "x-powers,axp805", "x-powers,axp806";
> + reg = <0x36>;
> + interrupt-parent = <_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + x-powers,self-working-mode;
> + vina-supply = <_vcc5v>;
> + vinb-supply = <_vcc5v>;
> + vinc-supply = <_vcc5v>;
> + vind-supply = <_vcc5v>;
> + vine-supply = <_vcc5v>;
> + aldoin-supply = <_vcc5v>;
> + bldoin-supply = <_vcc5v>;
> + cldoin-supply = <_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-pl";
> + };
> +
> + reg_aldo2: aldo2 {
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-ac200";
> + regulator-enable-ramp-delay = <10>;
> + };
> +
> + reg_aldo3: aldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc25-dram";
> + };
> +
> + reg_bldo1: bldo1 {
> + regulator-always-on;
>
[U-Boot] [PATCH] arm64: allwinner: sun50i: Sync H6 dts(i) files from Linux
Usually the Linux dts changes were synced in specific tags in Allwinner,
to keep track for whats been synced so-far and plan for future syncs.
But this patch sync sun50i-h6* dts(i) files from Linux w/o any specific
tag since these dts(i) changes are required for new H6 boards support.
Linux commit details about the sun50i-h6* sync:
"arm64: dts: allwinner: h6: move MMC pinctrl to dtsi"
(sha1: 6ba2e45d57afdfd982d12f168edd6a79a65075d8)
Linux commit details about the sun8i-tcon-top.h sync:
"dt-bindings: display: sunxi-drm: Add TCON TOP description"
(sha1: 59a9c39544cd1e5952c2a33028d71aa8180648f8)
Part of the sync initiated by 'Clément Péron'.
Signed-off-by: Clément Péron
Signed-off-by: Jagan Teki
---
arch/arm/dts/sun50i-h6-orangepi.dtsi | 62 +++-
arch/arm/dts/sun50i-h6-pine-h64.dts| 88 -
arch/arm/dts/sun50i-h6.dtsi| 398 -
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +
4 files changed, 538 insertions(+), 21 deletions(-)
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
diff --git a/arch/arm/dts/sun50i-h6-orangepi.dtsi
b/arch/arm/dts/sun50i-h6-orangepi.dtsi
index 0612c19cd9..62e27948a3 100644
--- a/arch/arm/dts/sun50i-h6-orangepi.dtsi
+++ b/arch/arm/dts/sun50i-h6-orangepi.dtsi
@@ -21,17 +21,55 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ power {
+ label = "orangepi:red:power";
+ gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ default-state = "on";
+ };
+
+ status {
+ label = "orangepi:green:status";
+ gpios = <_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
+ };
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the DC jack */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
};
{
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
vmmc-supply = <_cldo1>;
cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
bus-width = <4>;
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
_i2c {
status = "okay";
@@ -43,6 +81,14 @@
interrupt-controller;
#interrupt-cells = <1>;
x-powers,self-working-mode;
+ vina-supply = <_vcc5v>;
+ vinb-supply = <_vcc5v>;
+ vinc-supply = <_vcc5v>;
+ vind-supply = <_vcc5v>;
+ vine-supply = <_vcc5v>;
+ aldoin-supply = <_vcc5v>;
+ bldoin-supply = <_vcc5v>;
+ cldoin-supply = <_vcc5v>;
regulators {
reg_aldo1: aldo1 {
@@ -148,3 +194,15 @@
pinctrl-0 = <_ph_pins>;
status = "okay";
};
+
+ {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+ {
+ usb0_id_det-gpios = < 2 6 GPIO_ACTIVE_HIGH>; /* PC6 */
+ usb0_vbus-supply = <_vcc5v>;
+ usb3_vbus-supply = <_vcc5v>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
b/arch/arm/dts/sun50i-h6-pine-h64.dts
index ceffc40810..4802902e12 100644
--- a/arch/arm/dts/sun50i-h6-pine-h64.dts
+++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
@@ -14,6 +14,7 @@
compatible = "pine64,pine-h64", "allwinner,sun50i-h6";
aliases {
+ ethernet0 =
serial0 =
};
@@ -21,6 +22,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -39,23 +51,79 @@
gpios = <_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
};
};
+
+ reg_usb_vbus: vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ startup-delay-us = <10>;
+ gpio = <_pio 0 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
- {
+ {
pinctrl-names = "default";
- pinctrl-0 = <_pins>;
+ pinctrl-0 = <_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <_rgmii_phy>;
+ phy-supply = <_aldo2>;
+ allwinner,rx-delay-ps = <200>;
+ allwinner,tx-delay-ps =
Re: [U-Boot] [PATCH 3/4] Remove #define CONFIG_CRC32
Am 13.04.19 um 11:13 schrieb Chris Packham: > There is no check for CONFIG_CRC32 so the #define in image.h does > nothing. Remove it. > > Reported-by: Robert P. J. Day > Signed-off-by: Chris Packham > --- > > include/image.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/include/image.h b/include/image.h > index 765ffecee0a7..6b2661ed0bd6 100644 > --- a/include/image.h > +++ b/include/image.h > @@ -68,7 +68,6 @@ struct fdt_region; > # define IMAGE_ENABLE_SHA1 1 > # endif > # else > -# define CONFIG_CRC32 /* FIT images need CRC32 support */ > # define IMAGE_ENABLE_CRC32 1 > # define IMAGE_ENABLE_MD5 1 > # define IMAGE_ENABLE_SHA1 1 > Reviewed-by: Stefano Babic Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/8] video/console: Implement reverse video ANSI sequence for DM_VIDEO
From: Andre Przywara
The video console for DM_VIDEO compliant drivers only understands a very
small number of ANSI sequences. First and foremost it misses the "reverse
video" command, which is used by our own bootmenu command to highlight
the selected entry.
To avoid forcing people to use their imagination when using the
bootmenu, let's just implement the rather simple reverse effect. We need
to store the background colour index for that, so that we can
recalculate both the foreground and background colour pixel values.
Signed-off-by: Andre Przywara
Reviewed-by: Simon Glass
[agust: merged BG color escape seq change to fix "ut dm video_ansi" test]
Signed-off-by: Anatolij Gustschin
---
Changes in v2:
- Fix to render standard bg colors (as used to be before v1 2/8 patch).
Catched by "dm video_ansi" test.
drivers/video/vidconsole-uclass.c | 13 +++--
drivers/video/video-uclass.c | 1 +
include/video.h | 2 ++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/video/vidconsole-uclass.c
b/drivers/video/vidconsole-uclass.c
index 2ca19d4049..3ff65f3232 100644
--- a/drivers/video/vidconsole-uclass.c
+++ b/drivers/video/vidconsole-uclass.c
@@ -360,6 +360,13 @@ static void vidconsole_escape_char(struct udevice *dev,
char ch)
vid_priv->colour_fg = vid_console_color(
vid_priv, vid_priv->fg_col_idx);
break;
+ case 7:
+ /* reverse video */
+ vid_priv->colour_fg = vid_console_color(
+ vid_priv, vid_priv->bg_col_idx);
+ vid_priv->colour_bg = vid_console_color(
+ vid_priv, vid_priv->fg_col_idx);
+ break;
case 30 ... 37:
/* foreground color */
vid_priv->fg_col_idx &= ~7;
@@ -368,9 +375,11 @@ static void vidconsole_escape_char(struct udevice *dev,
char ch)
vid_priv, vid_priv->fg_col_idx);
break;
case 40 ... 47:
- /* background color */
+ /* background color, also mask the bold bit */
+ vid_priv->bg_col_idx &= ~0xf;
+ vid_priv->bg_col_idx |= val - 40;
vid_priv->colour_bg = vid_console_color(
- vid_priv, val - 40);
+ vid_priv, vid_priv->bg_col_idx);
break;
default:
/* ignore unsupported SGR parameter */
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index f307cf243b..14aac88d6d 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -136,6 +136,7 @@ void video_set_default_colors(struct udevice *dev, bool
invert)
back = temp;
}
priv->fg_col_idx = fore;
+ priv->bg_col_idx = back;
priv->colour_fg = vid_console_color(priv, fore);
priv->colour_bg = vid_console_color(priv, back);
}
diff --git a/include/video.h b/include/video.h
index 1d57b48b17..485071d072 100644
--- a/include/video.h
+++ b/include/video.h
@@ -70,6 +70,7 @@ enum video_log2_bpp {
* the LCD is updated
* @cmap: Colour map for 8-bit-per-pixel displays
* @fg_col_idx:Foreground color code (bit 3 = bold, bit 0-2 = color)
+ * @bg_col_idx:Background color code (bit 3 = bold, bit 0-2 = color)
*/
struct video_priv {
/* Things set up by the driver: */
@@ -92,6 +93,7 @@ struct video_priv {
bool flush_dcache;
ushort *cmap;
u8 fg_col_idx;
+ u8 bg_col_idx;
};
/* Placeholder - there are no video operations at present */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
On Fri, Apr 12, 2019 at 07:13:01PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > thanks, > Jagan. > > The following changes since commit 02f173ca156cee8526dff87603d5e446b443cde3: > > Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-11 14:29:37 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-spi.git master > > for you to fetch changes up to 59aea29a31869ed0fd5ffc4b95050db966fcaf6d: > > MAINTAINERS: Change Jagan's email address (2019-04-12 18:47:16 +0530) > 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 3/8] video/console: Implement relative cursor movement ANSI handling
Hi André, On Sat, 13 Apr 2019 22:40:03 +0100 André Przywara andre.przyw...@arm.com wrote: ... > > I've dropped all applied patches of this series now, some of them > > introduced dm video_ansi test error [1]. Please fix. Thanks! > > Hmh, good one. Didn't find an easy way to get to the bottom of this > within the ut test system, so I copied the ANSI sequences out and > replayed them with a custom command, inspecting the (sandbox) screen > manually. Is there a canonical way to trace down those issues? You can build sandbox defconfig an run U-Boot with "--show_lcd" option, then run the "ut dm video_ansi" command to inspect the rendered characters and colors, e.g.: $ make sandbox_defconfig $ make $ ./u-boot -d arch/sandbox/dts/test.dtb -l U-Boot 2019.04-00326-g7b64a70a3a (Apr 14 2019 - 14:37:44 +0200) Model: sandbox DRAM: 128 MiB MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD) In:serial Out: vidconsole Err: vidconsole Model: sandbox SCSI: Net: eth0: eth@10002000, eth5: eth@10003000, eth3: sbe5, eth1: eth@10004000 Hit any key to stop autoboot: 0 => ut dm video_ansi Test: dm_test_video_ansi: video.c Failures: 0 In the "U-Boot" window you will see the output of the video_ansi test. Without your fix for masking bit 3 in the bg index, the high-intensity background colors will be used, you will see brighter BG colors. The test expects results for standard background colors (indexes 0-7). > Anyway, the fix for patch 2/8 is rather simple (see below), do you want > to fix this up in your tree? Or shall I sent a v2? Thanks! I've merged your fix for patch 2/8, no need to resend. Build- testing now. -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] getting rid of clearly(?) obsolete doc/README* files?
before i submit a patch, i'll ask permission first -- is it worth submitting patches to delete what appear to be totally obsolete README files? i just stumbled over doc/README.ARM-memory-map, dated Sep 2003, which reads in part: "_armboot_start contains the value of CONFIG_SYS_TEXT_BASE (0xA07E); it seems CONFIG_SYS_TEXT_BASE and _armboot_start are both used for the same purpose in different parts of the (ARM) code. Furthermore, the startup code (cpu//start.S) internally uses another variable (_TEXT_BASE) with the same content as _armboot_start. I agree that this mess should be cleaned up." i checked -- there are no remaining references to _armboot_start, and there's this from 2011: commit 297f18ac0fbeef30ba1c17fe131ca75f09a6e7cf Author: Greg Ungerer Date: Fri Sep 9 22:23:34 2011 +1000 CM4000: fix broken flash base for OpenGear boards Use _bss_start_ofs as the size of the boot loader code+data that we want to protect in the flash. This replaces use of the no longer defined _armboot_start. ... etc etc ... under the circumstances, does that file have any current informational value? i'm pretty sure i've noticed a couple others that seem way out of date. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
On 4/14/19 1:40 PM, Robert P. J. Day wrote: > On Sun, 14 Apr 2019, Marek Vasut wrote: > >> On 4/14/19 12:51 PM, Robert P. J. Day wrote: >>> On Sun, 14 Apr 2019, Marek Vasut wrote: >>> On 4/14/19 12:06 PM, Robert P. J. Day wrote: > > Kbuild "select" directives should not include "CONFIG_" prefix. > > Signed-off-by: Robert P. J. Day The patch is correct, but does it have any side-effects ? > --- > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index ba1e6bfa43..96474f4e3b 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC > config USB_EHCI_FSL > bool "Support for FSL on-chip EHCI USB controller" > default n > - select CONFIG_EHCI_HCD_INIT_AFTER_RESET > + select EHCI_HCD_INIT_AFTER_RESET > ---help--- > Enables support for the on-chip EHCI controller on FSL chips. > endif # USB_EHCI_HCD > >>> >>> there are a *ton* of include/configs/ header files that >>> already contain: >>> >>> #define CONFIG_EHCI_HCD_INIT_AFTER_RESET >> >> And those boards also enable USB_EHCI_FSL ? If so, then it might >> also make sense to remove these #define >> CONFIG_EHCI_HCD_INIT_AFTER_RESET from the header files. >> >> I think ./tools/moveconfig.py could help you with that cleanup . > > ok, i'll take a closer look first chance i get. clearly, there's > potentially more cleanup here than just fixing a typo. Thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
On Sun, 14 Apr 2019, Marek Vasut wrote: > On 4/14/19 12:51 PM, Robert P. J. Day wrote: > > On Sun, 14 Apr 2019, Marek Vasut wrote: > > > >> On 4/14/19 12:06 PM, Robert P. J. Day wrote: > >>> > >>> Kbuild "select" directives should not include "CONFIG_" prefix. > >>> > >>> Signed-off-by: Robert P. J. Day > >> > >> The patch is correct, but does it have any side-effects ? > >> > >>> --- > >>> > >>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > >>> index ba1e6bfa43..96474f4e3b 100644 > >>> --- a/drivers/usb/host/Kconfig > >>> +++ b/drivers/usb/host/Kconfig > >>> @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC > >>> config USB_EHCI_FSL > >>> bool "Support for FSL on-chip EHCI USB controller" > >>> default n > >>> - select CONFIG_EHCI_HCD_INIT_AFTER_RESET > >>> + select EHCI_HCD_INIT_AFTER_RESET > >>> ---help--- > >>> Enables support for the on-chip EHCI controller on FSL chips. > >>> endif # USB_EHCI_HCD > >>> > > > > there are a *ton* of include/configs/ header files that > > already contain: > > > > #define CONFIG_EHCI_HCD_INIT_AFTER_RESET > > And those boards also enable USB_EHCI_FSL ? If so, then it might > also make sense to remove these #define > CONFIG_EHCI_HCD_INIT_AFTER_RESET from the header files. > > I think ./tools/moveconfig.py could help you with that cleanup . ok, i'll take a closer look first chance i get. clearly, there's potentially more cleanup here than just fixing a typo. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
On 4/14/19 12:51 PM, Robert P. J. Day wrote: > On Sun, 14 Apr 2019, Marek Vasut wrote: > >> On 4/14/19 12:06 PM, Robert P. J. Day wrote: >>> >>> Kbuild "select" directives should not include "CONFIG_" prefix. >>> >>> Signed-off-by: Robert P. J. Day >> >> The patch is correct, but does it have any side-effects ? >> >>> --- >>> >>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig >>> index ba1e6bfa43..96474f4e3b 100644 >>> --- a/drivers/usb/host/Kconfig >>> +++ b/drivers/usb/host/Kconfig >>> @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC >>> config USB_EHCI_FSL >>> bool "Support for FSL on-chip EHCI USB controller" >>> default n >>> - select CONFIG_EHCI_HCD_INIT_AFTER_RESET >>> + select EHCI_HCD_INIT_AFTER_RESET >>> ---help--- >>> Enables support for the on-chip EHCI controller on FSL chips. >>> endif # USB_EHCI_HCD >>> > > there are a *ton* of include/configs/ header files that > already contain: > > #define CONFIG_EHCI_HCD_INIT_AFTER_RESET And those boards also enable USB_EHCI_FSL ? If so, then it might also make sense to remove these #define CONFIG_EHCI_HCD_INIT_AFTER_RESET from the header files. I think ./tools/moveconfig.py could help you with that cleanup . > and the only test i can see for it is in drivers/usb/host/ehci-hcd.c: > > #if defined(CONFIG_EHCI_HCD_INIT_AFTER_RESET) > rc = ehci_hcd_init(index, init, >hccr, >hcor); > if (rc) > return rc; > #endif > > so i would *think* that, given the number of boards that already > explicitly include that feature, it's unlikely that fixing that > Kconfig file would suddenly reveal an issue that was hidden until now. > but that's just a guess. > > rday > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tbs2910 not buildable
Hi Stefano, On 14.04.19 13:24, Stefano Babic wrote: > Hi Soeren, > > On 14/04/19 12:46, Soeren Moch wrote: >> Hi Stefano, >> >> On 14.04.19 11:52, stefano babic wrote: >>> Hallo Soeren, >>> >>> after pulling from Tom and merging u-boot-imx, - next, your board is not >>> buildable anymore. Better: it is buildable, but size exceeds: >>> >>>arm: + tbs2910 >>> +u-boot.imx exceeds file size limit: >>> + limit: 392192 bytes >>> + actual: 396288 bytes >>> + excess: 4096 bytes >>> >>> Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this >>> board), solves the issue. I can do myself in this way or let me know >>> what is your preferred way. >>> >> Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it >> is supposed to provide a full PC environment. It supports booting from >> SATA, and such disk may as well be partitioned with EFI. It is really >> terrible to drop user visible features, just to support a new "driver >> model" that is supposed to ease life for developers, but in fact is much >> work and a real pain for maintainers of existing boards, and brings >> exactly nothing for the board's users. > I have explained my concerns in the past about footprint, too, but there > is nothing I can do. I know, therefore I cc'd Tom. > This is the way we have to go on and we have to > find solutions. > >> So much for that. Now to your question. >> >> Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more >> important to get this series merged, because other boards also depend on >> the SATA patches. We can readd EFI_PARTITION support later. For sure >> there will be more patches in this development cycle. >> But if you can wait a few hours, I will look for a better solution, or >> send a formal patch for this CONFIG_EFI_PARTITION removal. > Today is Sunday, I have also not expected you was fast to answer ;-) > > It is also fine for me to wait until tomorrow. OK, I will send a patch for that. Regards, Soeren > I just want to sent PR to > Tom as soon as possible, because there are many developers waiting for > the merge from -next. tbs2910 is the only board with issues from Travis, > and I can confirm that it is still ok on u-boot-imx, next. Something new > is slipped down between 2019.rc4 and 2019.04 and at the end had > increased again the footprint. > > Thanks for checking this, > > Stefano Babic > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tbs2910 not buildable
Hi Soeren, On 14/04/19 12:46, Soeren Moch wrote: > Hi Stefano, > > On 14.04.19 11:52, stefano babic wrote: >> Hallo Soeren, >> >> after pulling from Tom and merging u-boot-imx, - next, your board is not >> buildable anymore. Better: it is buildable, but size exceeds: >> >>arm: + tbs2910 >> +u-boot.imx exceeds file size limit: >> + limit: 392192 bytes >> + actual: 396288 bytes >> + excess: 4096 bytes >> >> Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this >> board), solves the issue. I can do myself in this way or let me know >> what is your preferred way. >> > Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it > is supposed to provide a full PC environment. It supports booting from > SATA, and such disk may as well be partitioned with EFI. It is really > terrible to drop user visible features, just to support a new "driver > model" that is supposed to ease life for developers, but in fact is much > work and a real pain for maintainers of existing boards, and brings > exactly nothing for the board's users. I have explained my concerns in the past about footprint, too, but there is nothing I can do. This is the way we have to go on and we have to find solutions. > > So much for that. Now to your question. > > Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more > important to get this series merged, because other boards also depend on > the SATA patches. We can readd EFI_PARTITION support later. For sure > there will be more patches in this development cycle. > But if you can wait a few hours, I will look for a better solution, or > send a formal patch for this CONFIG_EFI_PARTITION removal. Today is Sunday, I have also not expected you was fast to answer ;-) It is also fine for me to wait until tomorrow. I just want to sent PR to Tom as soon as possible, because there are many developers waiting for the merge from -next. tbs2910 is the only board with issues from Travis, and I can confirm that it is still ok on u-boot-imx, next. Something new is slipped down between 2019.rc4 and 2019.04 and at the end had increased again the footprint. Thanks for checking this, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
On Sun, 14 Apr 2019, Marek Vasut wrote: > On 4/14/19 12:06 PM, Robert P. J. Day wrote: > > > > Kbuild "select" directives should not include "CONFIG_" prefix. > > > > Signed-off-by: Robert P. J. Day > > The patch is correct, but does it have any side-effects ? > > > --- > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > index ba1e6bfa43..96474f4e3b 100644 > > --- a/drivers/usb/host/Kconfig > > +++ b/drivers/usb/host/Kconfig > > @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC > > config USB_EHCI_FSL > > bool "Support for FSL on-chip EHCI USB controller" > > default n > > - select CONFIG_EHCI_HCD_INIT_AFTER_RESET > > + select EHCI_HCD_INIT_AFTER_RESET > > ---help--- > > Enables support for the on-chip EHCI controller on FSL chips. > > endif # USB_EHCI_HCD > > there are a *ton* of include/configs/ header files that already contain: #define CONFIG_EHCI_HCD_INIT_AFTER_RESET and the only test i can see for it is in drivers/usb/host/ehci-hcd.c: #if defined(CONFIG_EHCI_HCD_INIT_AFTER_RESET) rc = ehci_hcd_init(index, init, >hccr, >hcor); if (rc) return rc; #endif so i would *think* that, given the number of boards that already explicitly include that feature, it's unlikely that fixing that Kconfig file would suddenly reveal an issue that was hidden until now. but that's just a guess. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tbs2910 not buildable
Hi Stefano, On 14.04.19 11:52, stefano babic wrote: > Hallo Soeren, > > after pulling from Tom and merging u-boot-imx, - next, your board is not > buildable anymore. Better: it is buildable, but size exceeds: > >arm: + tbs2910 > +u-boot.imx exceeds file size limit: > + limit: 392192 bytes > + actual: 396288 bytes > + excess: 4096 bytes > > Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this > board), solves the issue. I can do myself in this way or let me know > what is your preferred way. > Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it is supposed to provide a full PC environment. It supports booting from SATA, and such disk may as well be partitioned with EFI. It is really terrible to drop user visible features, just to support a new "driver model" that is supposed to ease life for developers, but in fact is much work and a real pain for maintainers of existing boards, and brings exactly nothing for the board's users. So much for that. Now to your question. Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more important to get this series merged, because other boards also depend on the SATA patches. We can readd EFI_PARTITION support later. For sure there will be more patches in this development cycle. But if you can wait a few hours, I will look for a better solution, or send a formal patch for this CONFIG_EFI_PARTITION removal. Thanks, Soeren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] very short list of "badref selects" in u-boot source
On Fri, 12 Apr 2019, Robert P. J. Day wrote: > rather than go to the trouble of whipping up a wiki page, i can > present this in a short post to the list. here's the list of what my > script identified as "badref selects" -- those identifiers for which > there is a Kconfig line of the form: > > select X > > where there is no corresponding: > > config X > > the entire list: > > > BOOTM_LINUX > > CONFIG_EHCI_HCD_INIT_AFTER_RESET > > CONFIG_MPC8xx_WATCHDOG > > CPU_ARM926EJS1 > > CRC32 > > GPIO > > MSCC_BITBANG_SPI_GPIO > > SPL_DISABLE_OF_CONTROL > > VEXPRESS_CLK ... snip ... between a couple patches i sent in and the more extensive submissions from chris packham, most of this list has been resolved except for three of them. a couple are isolated but i'm not sure what to do with them: $ git grep MSCC_BITBANG_SPI_GPIO arch/mips/mach-mscc/Kconfig:select MSCC_BITBANG_SPI_GPIO $ and: $ git grep VEXPRESS_CLK drivers/video/Kconfig: select VEXPRESS_CLK $ but it's BOOTM_LINUX that i'm unsure of: $ git grep BOOTM_LINUX common/bootm_os.c:#ifdef CONFIG_BOOTM_LINUX include/config_defaults.h:#define CONFIG_BOOTM_LINUX 1 include/configs/xilinx_versal_mini.h:#undef CONFIG_BOOTM_LINUX include/configs/xilinx_zynqmp_mini.h:#undef CONFIG_BOOTM_LINUX include/configs/zynq_cse.h:#undef CONFIG_BOOTM_LINUX lib/optee/Kconfig: select BOOTM_LINUX scripts/config_whitelist.txt:CONFIG_BOOTM_LINUX $ it's clear that CONFIG_BOOTM_LINUX is simply defined as a hard-coded macro in some header files, so what does it then mean if a Kconfig file selects it? i've never checked what the Kbuild infrastructure does in a case like that -- would it actually define CONFIG_BOOTM_LINUX, despite the fact that there is no associated BOOTM_LINUX Kbuild option? in any event, it's definitely messy. anyway, those are the remnants of "select" directives referring to non-existent Kbuild options. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] delete Kbuild "select" of long-dead SPL_DISABLE_OF_CONTROL
From way back in 2015: commit dffb86e468c8e02ba77283989aefef214d904dc5 Author: Masahiro Yamada Date: Wed Aug 12 07:31:54 2015 +0900 of: flip CONFIG_SPL_DISABLE_OF_CONTROL into CONFIG_SPL_OF_CONTROL As we discussed a couple of times, negative CONFIG options make our life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ... and here is another one. Now, there are three boards enabling OF_CONTROL on SPL: - socfpga_arria5_defconfig - socfpga_cyclone5_defconfig - socfpga_socrates_defconfig This commit adds CONFIG_SPL_OF_CONTROL for them and deletes CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert the logic. Signed-off-by: Masahiro Yamada Reviewed-by: Tom Rini Reviewed-by: Simon Glass --- AFAICT, simple deletion should be sufficient but i'm willing to be convinced otherwise. diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 3807770362..14347e7c7d 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -116,7 +116,6 @@ config TARGET_SNOW config TARGET_SPRING bool "Spring board" select OF_CONTROL - select SPL_DISABLE_OF_CONTROL select SUPPORT_SPL config TARGET_SMDK5420 @@ -150,7 +149,6 @@ config TARGET_ESPRESSO7420 select OF_CONTROL select PINCTRL select PINCTRL_EXYNOS7420 - select SPL_DISABLE_OF_CONTROL select SUPPORT_SPL endchoice -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
On 4/14/19 12:06 PM, Robert P. J. Day wrote: > > Kbuild "select" directives should not include "CONFIG_" prefix. > > Signed-off-by: Robert P. J. Day The patch is correct, but does it have any side-effects ? > --- > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index ba1e6bfa43..96474f4e3b 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC > config USB_EHCI_FSL > bool "Support for FSL on-chip EHCI USB controller" > default n > - select CONFIG_EHCI_HCD_INIT_AFTER_RESET > + select EHCI_HCD_INIT_AFTER_RESET > ---help--- > Enables support for the on-chip EHCI controller on FSL chips. > endif # USB_EHCI_HCD > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
Kbuild "select" directives should not include "CONFIG_" prefix. Signed-off-by: Robert P. J. Day --- diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index ba1e6bfa43..96474f4e3b 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC config USB_EHCI_FSL bool "Support for FSL on-chip EHCI USB controller" default n - select CONFIG_EHCI_HCD_INIT_AFTER_RESET + select EHCI_HCD_INIT_AFTER_RESET ---help--- Enables support for the on-chip EHCI controller on FSL chips. endif # USB_EHCI_HCD -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] tbs2910 not buildable
Hallo Soeren, after pulling from Tom and merging u-boot-imx, - next, your board is not buildable anymore. Better: it is buildable, but size exceeds: arm: + tbs2910 +u-boot.imx exceeds file size limit: + limit: 392192 bytes + actual: 396288 bytes + excess: 4096 bytes Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this board), solves the issue. I can do myself in this way or let me know what is your preferred way. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: core: Change platform specific translation-offset handling
Hi Stefan,
On Fri, Apr 12 2019, Stefan Roese wrote:
> Testing has shown that the current DM implementation of a platform /
> board specific translation offset, as its needed for the SPL on MVEBU
> platforms is buggy. The translation offset is confingured too late,
> after the driver bind functions are run. This may result in incorrect
> address translations. With the current implementation its not possible
> to configure the offset earlier, as the DM code has not run at all.
>
> This patch now removed the set_/get_translation_offset() calls and
> moves the translation offset into the GD variable translation_offset.
> This variable will get used when CONFIG_TRANSLATION_OFFSET is enabled.
> This option is enabled only for MVEBU on ARM32 platforms, where its
> currenty needed and configured in the SPL.
>
> Signed-off-by: Stefan Roese
> Cc: Pierre Bourdon
> Cc: Baruch Siach
> Cc: Simon Glass
> Cc: Heiko Schocher
> Cc: Tom Rini
Thanks. This fixes boot on Clearfog when I2C is enabled in SPL.
Tested-by: Baruch Siach
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: am57xx: cl-som-am57x: remove board support
U-Boot support for the CL-SOM-AM57x module is no longer required.
Signed-off-by: Uri Mashiach
---
arch/arm/dts/am57xx-cl-som-am57x.dts | 617 -
arch/arm/dts/am57xx-sbc-am57x.dts | 179 -
arch/arm/mach-omap2/omap5/Kconfig | 5 -
board/compulab/cl-som-am57x/Kconfig| 12 -
board/compulab/cl-som-am57x/MAINTAINERS| 6 -
board/compulab/cl-som-am57x/Makefile | 17 -
board/compulab/cl-som-am57x/cl-som-am57x.c | 78
board/compulab/cl-som-am57x/eth.c | 198 -
board/compulab/cl-som-am57x/mux.c | 123 --
board/compulab/cl-som-am57x/spl.c | 238 ---
configs/cl-som-am57x_defconfig | 64 ---
include/configs/cl-som-am57x.h | 148 ---
12 files changed, 1685 deletions(-)
delete mode 100644 arch/arm/dts/am57xx-cl-som-am57x.dts
delete mode 100644 arch/arm/dts/am57xx-sbc-am57x.dts
delete mode 100644 board/compulab/cl-som-am57x/Kconfig
delete mode 100644 board/compulab/cl-som-am57x/MAINTAINERS
delete mode 100644 board/compulab/cl-som-am57x/Makefile
delete mode 100644 board/compulab/cl-som-am57x/cl-som-am57x.c
delete mode 100644 board/compulab/cl-som-am57x/eth.c
delete mode 100644 board/compulab/cl-som-am57x/mux.c
delete mode 100644 board/compulab/cl-som-am57x/spl.c
delete mode 100644 configs/cl-som-am57x_defconfig
delete mode 100644 include/configs/cl-som-am57x.h
diff --git a/arch/arm/dts/am57xx-cl-som-am57x.dts
b/arch/arm/dts/am57xx-cl-som-am57x.dts
deleted file mode 100644
index 203266f884..00
--- a/arch/arm/dts/am57xx-cl-som-am57x.dts
+++ /dev/null
@@ -1,617 +0,0 @@
-/*
- * Support for CompuLab CL-SOM-AM57x System-on-Module
- *
- * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
- * Author: Dmitry Lifshitz
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- */
-
-/dts-v1/;
-
-#include
-#include
-#include "dra74x.dtsi"
-
-/ {
- model = "CompuLab CL-SOM-AM57x";
- compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742",
"ti,dra74", "ti,dra7";
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x8000 0x0 0x2000>; /* 512 MB - minimal
configuration */
- };
-
- leds {
- compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <_pins_default>;
-
- led0 {
- label = "cl-som-am57x:green";
- gpios = < 5 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
- };
-
- vdd_3v3: fixedregulator-vdd_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "vdd_3v3";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- ads7846reg: fixedregulator-ads7846-reg {
- compatible = "regulator-fixed";
- regulator-name = "ads7846-reg";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- sound0: sound0 {
- compatible = "simple-audio-card";
- simple-audio-card,name = "CL-SOM-AM57x-Sound-Card";
- simple-audio-card,format = "i2s";
- simple-audio-card,bitclock-master = <_master>;
- simple-audio-card,frame-master = <_master>;
- simple-audio-card,widgets =
- "Headphone", "Headphone Jack",
- "Microphone", "Microphone Jack",
- "Line", "Line Jack";
- simple-audio-card,routing =
- "Headphone Jack", "RHPOUT",
- "Headphone Jack", "LHPOUT",
- "LLINEIN", "Line Jack",
- "MICIN", "Mic Bias",
- "Mic Bias", "Microphone Jack";
-
- dailink0_master: simple-audio-card,cpu {
- sound-dai = <>;
- };
-
- simple-audio-card,codec {
- sound-dai = <>;
- system-clock-frequency = <1200>;
- };
- };
-};
-
-_pmx_core {
- leds_pins_default: leds_pins_default {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)
/* gpmc_a15.gpio2_5 */
- >;
- };
-
- i2c1_pins_default: i2c1_pins_default {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c1_sda.sda */
-
