[PATCH] video: dw_hdmi: Fix compiler warnings with gcc-14
GCC-14 find more warnings like
"make pointer from integer without a cast"
fix them by adding a type cast.
Signed-off-by: Khem Raj
Cc: Anatolij Gustschin
Cc: Tom Rini
---
drivers/video/dw_hdmi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/dw_hdmi.c b/drivers/video/dw_hdmi.c
index c4fbb18294..9294d9a82a 100644
--- a/drivers/video/dw_hdmi.c
+++ b/drivers/video/dw_hdmi.c
@@ -78,10 +78,10 @@ static void dw_hdmi_write(struct dw_hdmi *hdmi, u8 val, int
offset)
{
switch (hdmi->reg_io_width) {
case 1:
- writeb(val, hdmi->ioaddr + offset);
+ writeb(val, (void *)(hdmi->ioaddr + offset));
break;
case 4:
- writel(val, hdmi->ioaddr + (offset << 2));
+ writel(val, (void *)(hdmi->ioaddr + (offset << 2)));
break;
default:
debug("reg_io_width has unsupported width!\n");
@@ -93,9 +93,9 @@ static u8 dw_hdmi_read(struct dw_hdmi *hdmi, int offset)
{
switch (hdmi->reg_io_width) {
case 1:
- return readb(hdmi->ioaddr + offset);
+ return readb((void *)(hdmi->ioaddr + offset));
case 4:
- return readl(hdmi->ioaddr + (offset << 2));
+ return readl((void *)(hdmi->ioaddr + (offset << 2)));
default:
debug("reg_io_width has unsupported width!\n");
break;
--
2.43.0
[PATCH] riscv: fix build with binutils 2.38
>From version 2.38, binutils default to ISA spec version 20191213. This means that the csr read/write (csrr*/csrw*) instructions and fence.i instruction has separated from the `I` extension, become two standalone extensions: Zicsr and Zifencei. The fix is to specify those extensions explicitly in -march. However as older binutils version do not support this, we first need to detect that. Fixes arch/riscv/lib/cache.c: Assembler messages: arch/riscv/lib/cache.c:12: Error: unrecognized opcode `fence.i' Signed-off-by: Khem Raj Cc: Rick Chen Cc: Leo --- arch/riscv/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 0b80eb8d86..e6fe1fc02b 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -24,7 +24,12 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) CMODEL = medany endif -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \ +# Newer binutils versions default to ISA spec version 20191213 which moves some +# instructions from the I extension to the Zicsr and Zifencei extensions. +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C)_zicsr_zifencei) +zicsr_zifencei-$(toolchain-need-zicsr-zifencei) := _zicsr_zifencei + +ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C)$(zicsr_zifencei-y) -mabi=$(ABI) \ -mcmodel=$(CMODEL) PLATFORM_CPPFLAGS += $(ARCH_FLAGS) -- 2.35.1
[PATCH] riscv: fix build with binutils 2.38
>From version 2.38, binutils default to ISA spec version 20191213. This means that the csr read/write (csrr*/csrw*) instructions and fence.i instruction has separated from the `I` extension, become two standalone extensions: Zicsr and Zifencei. The fix is to specify those extensions explicitly in -march. However as older binutils version do not support this, we first need to detect that. Fixes arch/riscv/lib/cache.c: Assembler messages: arch/riscv/lib/cache.c:12: Error: unrecognized opcode `fence.i' Signed-off-by: Khem Raj Cc: Rick Chen Cc: Leo --- arch/riscv/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 0b80eb8d86..e6fe1fc02b 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -24,7 +24,12 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) CMODEL = medany endif -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \ +# Newer binutils versions default to ISA spec version 20191213 which moves some +# instructions from the I extension to the Zicsr and Zifencei extensions. +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C)_zicsr_zifencei) +zicsr_zifencei-$(toolchain-need-zicsr-zifencei) := _zicsr_zifencei + +ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C)$(zicsr_zifencei-y) -mabi=$(ABI) \ -mcmodel=$(CMODEL) PLATFORM_CPPFLAGS += $(ARCH_FLAGS) -- 2.35.1
[PATCH] riscv: fix build with binutils 2.38
>From version 2.38, binutils default to ISA spec version 20191213. This means that the csr read/write (csrr*/csrw*) instructions and fence.i instruction has separated from the `I` extension, become two standalone extensions: Zicsr and Zifencei. The fix is to specify those extensions explicitly in -march. However as older binutils version do not support this, we first need to detect that. Fixes arch/riscv/lib/cache.c: Assembler messages: arch/riscv/lib/cache.c:12: Error: unrecognized opcode `fence.i' Signed-off-by: Khem Raj Cc: Rick Chen Cc: Leo --- arch/riscv/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 0b80eb8d86..e6fe1fc02b 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -24,7 +24,12 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) CMODEL = medany endif -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \ +# Newer binutils versions default to ISA spec version 20191213 which moves some +# instructions from the I extension to the Zicsr and Zifencei extensions. +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C)_zicsr_zifencei) +zicsr_zifencei-$(toolchain-need-zicsr-zifencei) := _zicsr_zifencei + +ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C)$(zicsr_zifencei-y) -mabi=$(ABI) \ -mcmodel=$(CMODEL) PLATFORM_CPPFLAGS += $(ARCH_FLAGS) -- 2.35.1
Re: [U-Boot] [OE-core] [PATCH] u-boot: Upgrade to 2017.09
On Sun, Sep 17, 2017 at 2:18 AM, Martin Jansa wrote:
> Is anyone seeing u-boot-fw-utils.do_install failure with this?
>
I am seeing same failures too. havent yet dug into it.
> u-boot-fw-utils/1_2017.09-r0/git/tools/env/fw_printenv: No such file or
> directory
>
> I've tried u-boot-fw-utils-cross, but it fails as well even sooner in
> do_compile:
>
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 32 ARCH=arm CC=gcc
> -isystemwork/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/recipe-sysroot-native/usr/include
> -O2 -pipe
> -Lwork/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/recipe-sysroot-native/usr/lib
> -Lwork/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/recipe-sysroot-native/lib
> -Wl,-rpath-link,work/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/recipe-sysroot-native/usr/lib
> -Wl,-rpath-link,work/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/recipe-sysroot-native/lib
> -Wl,-rpath,work/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/recipe-sysroot-native/usr/lib
> -Wl,-rpath,work/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/recipe-sysroot-native/lib
> -Wl,-O1 V=1 rpi_3_32b_config
> | make -f ./scripts/Makefile.build obj=scripts/basic
> | cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c
> | /bin/sh: 1: cc: not found
> | make[1]: *** [scripts/basic/fixdep] Error 127
> | make: *** [scripts_basic] Error 2
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> work/x86_64-linux/u-boot-fw-utils-cross/1_2017.09-r0/temp/log.do_compile.12859)
> ERROR: Task
> (virtual:cross:oe-core/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb:do_compile)
> failed with exit code '1'
>
>
> On Mon, Sep 11, 2017 at 10:30 PM, Otavio Salvador
> wrote:
>>
>> This upgrades the U-Boot to the 2017.09 release.
>>
>> Signed-off-by: Otavio Salvador
>> ---
>>
>> .../u-boot/{u-boot-common_2017.07.inc => u-boot-common_2017.09.inc} |
>> 2 +-
>> .../u-boot/{u-boot-fw-utils_2017.07.bb => u-boot-fw-utils_2017.09.bb} |
>> 0
>> .../u-boot/{u-boot-mkimage_2017.07.bb => u-boot-mkimage_2017.09.bb} |
>> 0
>> meta/recipes-bsp/u-boot/{u-boot_2017.07.bb => u-boot_2017.09.bb}|
>> 0
>> 4 files changed, 1 insertion(+), 1 deletion(-)
>> rename meta/recipes-bsp/u-boot/{u-boot-common_2017.07.inc =>
>> u-boot-common_2017.09.inc} (89%)
>> rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2017.07.bb =>
>> u-boot-fw-utils_2017.09.bb} (100%)
>> rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2017.07.bb =>
>> u-boot-mkimage_2017.09.bb} (100%)
>> rename meta/recipes-bsp/u-boot/{u-boot_2017.07.bb => u-boot_2017.09.bb}
>> (100%)
>>
>> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2017.07.inc
>> b/meta/recipes-bsp/u-boot/u-boot-common_2017.09.inc
>> similarity index 89%
>> rename from meta/recipes-bsp/u-boot/u-boot-common_2017.07.inc
>> rename to meta/recipes-bsp/u-boot/u-boot-common_2017.09.inc
>> index e37f5fd409..02e51242cb 100644
>> --- a/meta/recipes-bsp/u-boot/u-boot-common_2017.07.inc
>> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2017.09.inc
>> @@ -7,7 +7,7 @@ PE = "1"
>>
>> # We use the revision in order to avoid having to fetch it from the
>> # repo during parse
>> -SRCREV = "d85ca029f257b53a96da6c2fb421e78a003a9943"
>> +SRCREV = "c98ac3487e413c71e5d36322ef3324b21c6f60f9"
>>
>> SRC_URI = "git://git.denx.de/u-boot.git \
>> file://MPC8315ERDB-enable-DHCP.patch \
>> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.07.bb
>> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
>> similarity index 100%
>> rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.07.bb
>> rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
>> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.07.bb
>> b/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.09.bb
>> similarity index 100%
>> rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2017.07.bb
>> rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2017.09.bb
>> diff --git a/meta/recipes-bsp/u-boot/u-boot_2017.07.bb
>> b/meta/recipes-bsp/u-boot/u-boot_2017.09.bb
>> similarity index 100%
>> rename from meta/recipes-bsp/u-boot/u-boot_2017.07.bb
>> rename to meta/recipes-bsp/u-boot/u-boot_2017.09.bb
>> --
>> 2.14.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> openembedded-c...@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] x86 build is broken with GCC 7
On Tue, Jun 20, 2017 at 7:47 AM Otavio Salvador < otavio.salva...@ossystems.com.br> wrote: > On Tue, Jun 20, 2017 at 11:41 AM, Tom Rini wrote: > > On Wed, Jun 14, 2017 at 09:53:37AM -0300, Otavio Salvador wrote: > > > >> Hello folks, > >> > >> Testing with current compiler exposed an error: > >> > >> arch/x86/lib/built-in.o: In function `__wrap___udivdi3': > >> /home/otavio/src/u-boot/arch/x86/lib/gcc.c:25: undefined reference to > >> `__normal___udivdi3' > >> > >> Is it a known issue? These functions come from libgcc so it seems you are not having libgcc specified or its missing completely sometimes it depends on compiler versions code generation whether it will generate calls to helpers from libgcc or not Important question is if uboot links with libgcc or not if it doesn't then you have to rewrite the code so that it doesn't generate the calls to this helper function or have it implemented in uboot code > > > > > Yes, building the 32bit x86 targets with a 64bit default gcc at least > > doesn't work. I actually forgot until the other day that I had just > > been relying on travis-ci for that part of my build testing. > > This is important; it works with GCC 6 but fails with GCC 7. Khem, is > it possible for you to help here? > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Patchwork housekeeping
On Thu, Mar 22, 2012 at 10:22 AM, Tom Rini wrote: I don't know if anyone has noticed, but patchwork is starting to collect a rather large amount of cruft. >>> >>> >>> >>> Do we, or do we not have the magic "update patchwork when the master repo >>> gets a patch" hook setup? It's not fool-proof, but it works well. >> >> >> Where does one find this? > > > I'm just a user over in OpenEmbedded-land where it's in use. Khem? Yes. I am the one who set it up on OE. Its setup as post-receive hook. I am attaching the sample to this mail. Thanks -Khem post-receive.patchwork.oe Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
