public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>,
	1003490@bugs.debian.org, u-boot@lists.denx.de,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target
Date: Tue, 25 Jan 2022 17:03:09 -0800	[thread overview]
Message-ID: <87ilu7b96a.fsf@ponder> (raw)
In-Reply-To: <YeLmODRhLSqiwb25@aurel32.net>

[-- Attachment #1: Type: text/plain, Size: 5388 bytes --]

A bug in Debian is causing a build failure of the qemu-ppce500 target:

  https://bugs.debian.org/1003490

I've CCed u-boot in case they're not aware of the issue.

Some background follows...

On 2022-01-15, Aurelien Jarno wrote:
> On 2022-01-11 16:40, Vagrant Cascadian wrote:
>> On 2022-01-11, Lennart Sorensen wrote:
>> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
>> >> Something in the toolchain recently changed which causes u-boot arch:all
>> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
>> >> works fine where binutils hasn't yet migrated.
>> >> 
>> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
>> >> 
>> >> Full log:
>> >> 
>> >>   https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=all&ver=2022.01%2Bdfsg-1&stamp=1641860624&raw=0
>> >> 
>> >> The hopefully relevent lines from the build log:
>> >> 
>> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/cpu/mpc85xx/.tlb.o.d -nostdinc -isystem /usr/lib/gcc-cross/powerpc-linux-gnu/11/include -Iinclude  -I/<<PKGBUILDDIR>>/include  -I/<<PKGBUILDDIR>>/arch/powerpc/include -include /<<PKGBUILDDIR>>/include/linux/kconfig.h  -I/<<PKGBUILDDIR>>/arch/powerpc/cpu/mpc85xx -Iarch/powerpc/cpu/mpc85xx -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -fno-strict-aliasing -fno-PIE -Os -fno-stack-protector -fno-delete-null-pointer-checks -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-maybe-uninitialized -fmacro-prefix-map=/<<PKGBUILDDIR>>/= -g -fstack-usage -Wno-format-nonliteral -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=date-time -Wno-packed-not-aligned -D__powerpc__ -ffixed-r2 -m32 -fno-ira-hoist-pressure -Wa,-me500 -msoft-float -mno-string -fpic -mrelocatable -ffunction-sections -fdata-sections -mcall-linux -msingle-pic-base -fno-jump-tables -pipe    -DKBUILD_BASENAME='"tlb"'  -DKBUILD_MODNAME='"tlb"' -c -o arch/powerpc/cpu/mpc85xx/tlb.o /<<PKGBUILDDIR>>/arch/powerpc/cpu/mpc85xx/tlb.c
>> >> ...
>> >> {standard input}: Assembler messages:
>> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
>> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
>> >> {standard input}:821: Error: unrecognized opcode: `msync'
>> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
>> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
>> >> make[4]: *** [/<<PKGBUILDDIR>>/scripts/Makefile.build:253: arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
>> >> make[3]: *** [/<<PKGBUILDDIR>>/Makefile:1810: arch/powerpc/cpu/mpc85xx] Error 2
>> >> make[3]: *** Waiting for unfinished jobs....
>> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
...
>> The binutils versions appear to be:
>> 
>>   succeeding, bookworm 2.37-10.1
>>   failing, sid 2.37.50.20220106-2
>> 
>
> Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
> the binutils side [1], which changes the behavior of `.machine`
> directives to override, rather than augment, the base CPU. GCC is called
> with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
> side, but as the default GCC machine is ppc, a `.set machine ppc` is
> emitted at the beginning of the assembly code.
>
> One option would be to force the CPU to e500 on the GCC side, however
> support for it has been removed. The options is therefore to force the
> machine in the assembly code. This is what the attached patch does.

Somehow I missed that you had attached a patch! I will try to get this
tested and uploaded to Debian soon...

live well,
  vagrant

> --- u-boot-2022.01+dfsg.orig/arch/powerpc/cpu/mpc85xx/tlb.c
> +++ u-boot-2022.01+dfsg/arch/powerpc/cpu/mpc85xx/tlb.c
> @@ -50,7 +50,10 @@ void read_tlbcam_entry(int idx, u32 *val
>  	u32 _mas1;
>  
>  	mtspr(MAS0, FSL_BOOKE_MAS0(1, idx, 0));
> -	asm volatile("tlbre;isync");
> +	asm volatile(".machine push;\n"
> +		     ".machine e500;\n"
> +		     "tlbre;isync;\n"
> +		     ".machine pop;\n");
>  	_mas1 = mfspr(MAS1);
>  
>  	*valid = (_mas1 & MAS1_VALID);
> @@ -109,7 +112,10 @@ void init_used_tlb_cams(void)
>  	/* walk all the entries */
>  	for (i = 0; i < num_cam; i++) {
>  		mtspr(MAS0, FSL_BOOKE_MAS0(1, i, 0));
> -		asm volatile("tlbre;isync");
> +		asm volatile(".machine push;\n"
> +			     ".machine e500;\n"
> +			     "tlbre;isync;\n"
> +			     ".machine pop;");
>  		if (mfspr(MAS1) & MAS1_VALID)
>  			use_tlb_cam(i);
>  	}
> @@ -183,7 +189,10 @@ void disable_tlb(u8 esel)
>  #ifdef CONFIG_ENABLE_36BIT_PHYS
>  	mtspr(MAS7, 0);
>  #endif
> -	asm volatile("isync;msync;tlbwe;isync");
> +	asm volatile(".machine push;\n"
> +		     ".machine e500;\n"
> +		     "isync;msync;tlbwe;isync;\n"
> +		     ".machine pop;\n");
>  
>  #ifdef CONFIG_ADDR_MAP
>  	if (gd->flags & GD_FLG_RELOC)
> @@ -193,7 +202,11 @@ void disable_tlb(u8 esel)
>  
>  static void tlbsx (const volatile unsigned *addr)
>  {
> -	__asm__ __volatile__ ("tlbsx 0,%0" : : "r" (addr), "m" (*addr));
> +	__asm__ __volatile__ (".machine push;\n"
> +			      ".machine e500;\n"
> +			      "tlbsx 0,%0;\n"
> +			      ".machine pop;\n"
> +			      : : "r" (addr), "m" (*addr));
>  }
>  
>  /* return -1 if we didn't find anything */

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

       reply	other threads:[~2022-01-26  1:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87wnj7oz6b.fsf@ponder>
     [not found] ` <Yd4UYNsgSutYk/Zh@csclub.uwaterloo.ca>
     [not found]   ` <87sftt4wi4.fsf@ponder>
     [not found]     ` <YeLmODRhLSqiwb25@aurel32.net>
2022-01-26  1:03       ` Vagrant Cascadian [this message]
2022-01-26  3:04         ` Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target Vagrant Cascadian
2022-01-26  7:43           ` Aurelien Jarno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ilu7b96a.fsf@ponder \
    --to=vagrant@debian.org \
    --cc=1003490@bugs.debian.org \
    --cc=aurelien@aurel32.net \
    --cc=lsorense@csclub.uwaterloo.ca \
    --cc=sstabellini@kernel.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox