This kernel fails to boot on baremetal also.

Enter choice: 1:        Fedora (4.5.0-0.rc1.git1.1.fc24.armv7hl) 23 (Twenty Three)
Retrieving file: /initramfs-4.5.0-0.rc1.git1.1.fc24.armv7hl.img
14830723 bytes read in 487 ms (29 MiB/s)
Retrieving file: /vmlinuz-4.5.0-0.rc1.git1.1.fc24.armv7hl
6593544 bytes read in 220 ms (28.6 MiB/s)
no console= 
append: ro root=UUID=e098e36f-f409-44cb-9d8e-9d5c0e2ed9c9 LANG=en_US.UTF-8 console=ttyS0,115200
Retrieving file: /dtb-4.5.0-0.rc1.git1.1.fc24.armv7hl/sun7i-a20-cubietruck.dtb
30801 bytes read in 534 ms (55.7 KiB/s)
Kernel image @ 0x42000000 [ 0x000000 - 0x649c08 ]
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Ramdisk to 4f1db000, end 4ffffc83 ... OK
   Loading Device Tree to 4f1d0000, end 4f1da850 ... OK

Starting kernel ...

[and here it hangs, apparently forever]

The hardware is a CubieTruck.

FWIW 4.5.0-0.rc1.git1.1.fc24.armv7hl+lpae does not boot either.

4.5.0-0.rc1.git0.2.fc24.armv7hl DOES boot OK.

Same here, tested on Banana Pi, I'm unable to boot since rawhide 20160130, 
(affected kernels: kernel-4.5.0-0.rc1.git2.1.fc24.armv7hl.rpm, kernel-4.5.0-0.rc2.git1.1.fc24.armv7hl.rpm)


As pwhalen mentioned, it seems to be specific for vexpress and allwinner:
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/thread/MT4CL4LRARX555QRUFZ6AHXSXFEPDFEJ/

(In reply to Lukas Brabec from comment #3)
> Same here, tested on Banana Pi, I'm unable to boot since rawhide 20160130, 
> (affected kernels: kernel-4.5.0-0.rc1.git2.1.fc24.armv7hl.rpm,
> kernel-4.5.0-0.rc2.git1.1.fc24.armv7hl.rpm)
> 
> 
> As pwhalen mentioned, it seems to be specific for vexpress and allwinner:
> https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/
> thread/MT4CL4LRARX555QRUFZ6AHXSXFEPDFEJ/

It affects qemu -M virt too.  See comment #0.

OK this looks to be an issue with the new binutils, when the kernel is built with the f23 userspace it works as expected and the version that has issues was the first build with the new binutils

*** Bug 1306568 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

OK, I've spend some time over the weekend digging into this further to try and get to the bottom of it.

To summarise the last kernel to boot correctly was 4.5.0-0.rc1.git0.2.fc24 and from then on 4.5.0-0.rc1.git1.1.fc24 doesn't on some ARMv7 SoCs. 

AllWinner, VExpress, some tegra (at least tk1/124) appear to be affected. i.MX6, am33xx, omap, mvebu aren't affected and work fine. There's possibly others that are/aren't affected that I've not yet tested.

Two koji build tasks:
4.5.0-0.rc1.git0.2.fc24: http://koji.fedoraproject.org/koji/buildinfo?buildID=714169
4.5.0-0.rc1.git1.1.fc24: http://koji.fedoraproject.org/koji/buildinfo?buildID=714524

I was wrong on the binutils, the major change here in the toolchain was the landing of gcc6. binutils was already at 2.26-3.fc24 for the last working kernel.

The diff of the buildroot package differences on the above working/not working kernels is:

-00kernel/4.5.0/0.rc1.git0.2.fc24
+00kernel/4.5.0/0.rc1.git1.1.fc24
-  binutils                     armv7hl 2.26-3.fc24                     build 5.5 M
-  binutils-devel               armv7hl 2.26-3.fc24                    build 712 k
+  binutils                     armv7hl 2.26-4.fc24                     build 5.5 M
+  binutils-devel               armv7hl 2.26-4.fc24                    build 710 k
-  cpp                          armv7hl 5.3.1-3.fc24                    build 6.8 M
+  cpp                          armv7hl 6.0.0-0.5.fc24                  build 7.1 M
-  dnf-plugins-core             noarch  0.1.16-1.fc24                   build  36 k
+  dnf-plugins-core             noarch  0.1.16-2.fc24                   build  36 k
-  elfutils                     armv7hl 0.165-2.fc24                    build 290 k
-  elfutils-default-yama-scope  noarch  0.165-2.fc24                    build  36 k
-  elfutils-devel               armv7hl 0.165-2.fc24                   build  92 k
-  elfutils-libelf              armv7hl 0.165-2.fc24                    build 209 k
-  elfutils-libelf-devel        armv7hl 0.165-2.fc24                   build  43 k
-  elfutils-libs                armv7hl 0.165-2.fc24                    build 257 k
+  elfutils                     armv7hl 0.165-3.fc24                    build 289 k
+  elfutils-default-yama-scope  noarch  0.165-3.fc24                    build  37 k
+  elfutils-devel               armv7hl 0.165-3.fc24                   build  92 k
+  elfutils-libelf              armv7hl 0.165-3.fc24                    build 210 k
+  elfutils-libelf-devel        armv7hl 0.165-3.fc24                   build  43 k
+  elfutils-libs                armv7hl 0.165-3.fc24                    build 257 k
-  file                         armv7hl 5.25-4.fc24                     build  66 k
-  file-libs                    armv7hl 5.25-4.fc24                     build 433 k
+  file                         armv7hl 5.25-5.fc24                     build  66 k
+  file-libs                    armv7hl 5.25-5.fc24                     build 433 k
-  gcc                          armv7hl 5.3.1-3.fc24                    build  15 M
-  gcc-c++                      armv7hl 5.3.1-3.fc24                    build 8.0 M
-  gcc-gdb-plugin               armv7hl 5.3.1-3.fc24                    build  72 k
+  gcc                          armv7hl 6.0.0-0.5.fc24                  build  15 M
+  gcc-c++                      armv7hl 6.0.0-0.5.fc24                  build 8.4 M
+  gcc-gdb-plugin               armv7hl 6.0.0-0.5.fc24                  build  55 k
-  glibc                        armv7hl 2.22.90-29.fc24                 build 3.3 M
-  glibc-common                 armv7hl 2.22.90-29.fc24                 build  12 M
-  glibc-devel                  armv7hl 2.22.90-29.fc24                 build 915 k
-  glibc-headers                armv7hl 2.22.90-29.fc24                 build 478 k
+  glibc                        armv7hl 2.22.90-31.fc24                 build 3.4 M
+  glibc-common                 armv7hl 2.22.90-31.fc24                 build  12 M
+  glibc-devel                  armv7hl 2.22.90-31.fc24                 build 928 k
+  glibc-headers                armv7hl 2.22.90-31.fc24                 build 478 k
-  go-srpm-macros               noarch  2-4.fc24                        build 7.3 k
+  go-srpm-macros               noarch  2-5.fc24                        build 7.1 k
-  kernel-headers               armv7hl 4.5.0-0.rc1.git0.1.fc24         build 1.0 M
+  kernel-headers               armv7hl 4.5.0-0.rc1.git0.2.fc24         build 1.0 M
-  krb5-libs                    armv7hl 1.14-17.fc24                    build 755 k
+  krb5-libs                    armv7hl 1.14-18.fc24                    build 756 k
-  libasan                      armv7hl 5.3.1-3.fc24                    build 262 k
+  libasan                      armv7hl 6.0.0-0.5.fc24                  build 288 k
-  libatomic                    armv7hl 5.3.1-3.fc24                    build  32 k
+  libatomic                    armv7hl 6.0.0-0.5.fc24                  build  13 k
-  libgcc                       armv7hl 5.3.1-3.fc24                    build  84 k
+  libgcc                       armv7hl 6.0.0-0.5.fc24                  build  65 k
-  libgomp                      armv7hl 5.3.1-3.fc24                    build 146 k
+  libgomp                      armv7hl 6.0.0-0.5.fc24                  build 161 k
-  libstdc++                    armv7hl 5.3.1-3.fc24                    build 370 k
-  libstdc++-devel              armv7hl 5.3.1-3.fc24                    build 1.7 M
+  libstdc++                    armv7hl 6.0.0-0.5.fc24                  build 355 k
+  libstdc++-devel              armv7hl 6.0.0-0.5.fc24                  build 1.8 M
-  libtool-ltdl                 armv7hl 2.4.6-8.fc24                    build  51 k
-  libubsan                     armv7hl 5.3.1-3.fc24                    build 115 k
+  libtool-ltdl                 armv7hl 2.4.6-9.fc24                    build  51 k
+  libubsan                     armv7hl 6.0.0-0.5.fc24                  build 103 k
-  openssl-libs                 armv7hl 1:1.0.2e-5.fc24                 build 831 k
+  openssl-libs                 armv7hl 1:1.0.2f-1.fc24                 build 831 k
-  python3-dnf-plugins-core     noarch  0.1.16-1.fc24                   build  80 k
+  python3-dnf-plugins-core     noarch  0.1.16-2.fc24                   build  80 k

Of the above the only possible components that look like they might cause issues is gcc 6, binutils bump, elfutils, and glibc.

The obvious one was gcc 6, and with a local compile using:
binutils-2.26-13.fc24.armv7hl
gcc-5.3.1-3.fc24.armv7hl
elfutils-0.165-5.fc24.armv7hl
glibc-2.22.90-36.fc24.armv7hl

So with just gcc downgraded to the last 5.3 rev shipped in F-24 we have a working boot on an AllWinner based Cubietruck indicating the problem is in fact gcc6.

So the CubieTruck and Jetson TK1 which previously ceased to boot with a 4.5.0-0.rc1.git1.1.fc24 or later kernel now boot with one compiled with binutils 2.26+ and gcc 5.3.1.

For those that wish to test you can grab the kernel from:
https://pbrobinson.fedorapeople.org/arm-kernel/

So, can somebody bisect this to a particular kernel source file?
Start with building two same kernels, build one with gcc 6.0 prerelease, another one with gcc 5.3.1, and then copy that to another tree and always mix them some portion of gcc 6.0 built object files and 5.3.1 built object files, touch them and relink, test.
Perhaps with knowing roughly what is going on or at least where the bisection might be speeded up by only trying a couple of suspicious object files.

> So, can somebody bisect this to a particular kernel source file?

I'm not sure what you mean by this. If I build the identical kernel src.rpm with gcc 6 it doesn't boot, if I build the same src.rpm with gcc 5.3.1 it doesn't boot.

> Start with building two same kernels, build one with gcc 6.0 prerelease,
> another one with gcc 5.3.1, and then copy that to another tree and always
> mix them some portion of gcc 6.0 built object files and 5.3.1 built object
> files, touch them and relink, test.

That process doesn't make sense when a kernel that's built on gcc 5.3.1 and the same kernel doesn't work on gcc6

What doesn't make sense?
If gcc 5.3.1 builds a working kernel and gcc 6 non-working, but both are ABI compatible (they should be), then you can try linking say first half of *.o files
created with gcc 5.3.1 with rest of *.o files created with gcc 6, if that boots, copy over a quarter of further gcc 6 created files, if it doesn't boot, copy over a quarter of further gcc 5.3.1 generated files, etc., until you have either
a single gcc 6 compiled file and all others 5.3.1 which still fails to boot, or
all gcc 6 compiled except one, compiled with 5.3.1 that does boot.  This of course assumes the problem is just in a single file, which is the most common case.  At that point, attach the preprocessed source and gcc command line options used to compile it.

When I copy arch/arm/kernel/setup.o from gcc 5.3.1 build to my gcc 6.0.0 build then resulting kernel boots.

Created attachment 1132725 [details]
gcc 5.3.1 preprocessed source of arch/arm/kernel/setup.c

make arch/arm/kernel/setup.o V=1
[...]
  gcc -Wp,-MD,arch/arm/kernel/.setup.o.d  -nostdinc -isystem /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/5.3.1/include -I./arch/arm/include -Iarch/arm/include/generated/uapi -Iarch/arm/include/generated  -Iinclude -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-dwarf2-cfi-asm -fno-ipa-sra -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -funwind-tables -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fvar-tracking-assignments -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(setup)"  -D"KBUILD_MODNAME=KBUILD_STR(setup)" -c -o arch/arm/kernel/setup.o arch/arm/kernel/setup.c

Created attachment 1132726 [details]
gcc 6.0.0 preprocessed source of arch/arm/kernel/setup.c

<mock-chroot>[mockbuild@localhost linux-4.5.0-0.rc6.git0.1.fc25.armv7hl]$   gcc -Wp,-MD,arch/arm/kernel/.setup.o.d  -nostdinc -isystem /usr/lib/gcc/armv7hl-gnueabi/6.0.0/include -I./arch/arm/include -Iarch/arm/include/generated/uapi -Iarch/arm/include/generated  -Iinclude -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-dwarf2-cfi-asm -fno-ipa-sra -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -funwind-tables -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fvar-tracking-assignments -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(setup)"  -D"KBUILD_MODNAME=KBUILD_STR(setup)" -c -o arch/arm/kernel/setup.o arch/arm/kernel/setup.c

One extra datapoint / something to keep in mind, I've just found out the hardway that it is not just an issue with kernels build with gcc-6 but also with u-boot build with gcc-6 (at least on allwinner A23 SoCs).

The u-boot issue is more subtle / nasty, u-boot seems to work as it should but the kernel hangs during boot when u-boot is build with gcc-6. Not 100% sure this is the case but downgrading gcc and then rebuilding u-boot fixed the boot issue I was having.

Note lets first fix the kernel thing, hopefully the u-boot fix will be similar, or if this is a gcc issue, the gcc fix will also fix u-boot.

Does building that file with -O0 help?  Or -O2 instead of -Os?
If yes, can you try adding __attribute__((optimize (0))) to some functions and see which function in that file matters?
Does -Os -fno-inline still crash?  If yes, the above would be somewhat easier with -fno-inline on the command line.
Otherwise, I could try to provide you assembly files built with different revisions of gcc, but that would need to be interactive process, as I have no way to reproduce this myself.

(In reply to Jakub Jelinek from comment #17)
> Does building that file with -O0 help?  Or -O2 instead of -Os?

> If yes, can you try adding __attribute__((optimize (0))) to some functions
> and see which function in that file matters?

> Does -Os -fno-inline still crash?  If yes, the above would be somewhat
> easier with -fno-inline on the command line.

Will check those hints on Monday.

> Otherwise, I could try to provide you assembly files built with different
> revisions of gcc, but that would need to be interactive process, as I have
> no way to reproduce this myself.

I used qemu for tests:

qemu-system-arm  -serial stdio -append "console=ttyAMA0 earlyprintk" -M virt -kernel zImage

setup.c built with -O0  boots. -O1 does not. Will check which optimization breaks.

Well, -O1 enables lots of changes that aren't controllable by other optimization flags.
Does -O1 -fno-inline boot or not?  If it doesn't, then I'd go with -O1 -fno-inline, and selectively adding __attribute__((optimize (0))) to various functions.

According to gcc docs at https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html this should be equal to -O1:

-O0 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap -fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time

But resulting kernel boots. Will go for __attribute__ check now.

-O1 -fno-inline does not boot.

__attribute__((optimize (0))) static void __init patch_aeabi_idiv(void)

and kernel boots!

(In reply to Marcin Juszkiewicz from comment #22)
> __attribute__((optimize (0))) static void __init patch_aeabi_idiv(void)
> 
> and kernel boots!

That's with default -Os optimisations.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/kernel/setup.c?id=42f25bddd0a226d2431e057b9e01c5cc61067e12 is faulty commit.

Disabling CONFIG_ARM_PATCH_IDIV in config makes kernel bootable again.

Will mail Nicolas Pitre.

(In reply to Marcin Juszkiewicz from comment #24)
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/
> arm/kernel/setup.c?id=42f25bddd0a226d2431e057b9e01c5cc61067e12 is faulty
> commit.

The question is why that works on gcc 5.3.1 and breaks on gcc 6

Created attachment 1133886 [details]
setup.c ASM source when built with gcc 5.3.1 (-save-temps used)

I built setup.o with "-save-temps" option.

Created attachment 1133887 [details]
setup.c ASM source when built with gcc 6.0.0 (-save-temps used)

If the kernel still boots if you add -fno-inline when you compile setup.c with gcc 5.3 and breaks if you add -fno-inline when you compile setup.c with gcc 6, can you please attach the assembly you get with the additional -fno-inline -dA
options in addition to what you used (have just cross-compiler here and want to verify I'm looking at the same code).  patch_eabi_idiv is pretty short function, so hope something can be discovered just from eyeballing the assembly.

Actually, I can see it already.
DSE1 does:
  Deleted dead store '*fn_addr.35_20 = 3876647184;
  Deleted dead store '*fn_addr.35_9 = 3878744336;
so removes the stores of the first instructions (and keeps the second instructions).  It would be certainly safer if the kernel used some optimization barrier, like:
 fn_addr = (uintptr_t)&__aeabi_uidiv;
 asm volatile ("" : "+g" (fn_addr));
 fn_addr &= ~1;
(and similarly for __aeabi_idiv).  But I'll have a look why DSE removes it and when it started.
Reduced testcase:
extern void v7_coherent_kern_range(unsigned long, unsigned long);

void patch_aeabi_idiv(void)
{
 extern void __aeabi_uidiv(void);
 extern void __aeabi_idiv(void);
 unsigned long fn_addr;

 fn_addr = ((unsigned long)&__aeabi_uidiv) & ~1;
 ((unsigned int *)fn_addr)[0] = 0xe730f110;
 ((unsigned int *)fn_addr)[1] = 0xe12fff1e;
 v7_coherent_kern_range(fn_addr,fn_addr + 8);

 fn_addr = ((unsigned long)&__aeabi_idiv) & ~1;
 ((unsigned int *)fn_addr)[0] = 0xe710f110;
 ((unsigned int *)fn_addr)[1] = 0xe12fff1e;
 v7_coherent_kern_range(fn_addr,fn_addr + 8);
}

Strangely, the above with -fno-strict-aliasing -fno-common -std=gnu89 -fno-ipa-sra -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -march=armv7-a -msoft-float -fno-delete-null-pointer-checks -Os the ((unsigned int *)fn_addr)[0] stores are removed already by gcc 5 too and even older compilers.

Great work Jakub!

I saw the changelog entry:

Disble ARM_PATCH_IDIV as a work around to fix rhbz 1303147

in kernel-4.5.0-0.rc7.git0.2.fc24, and that kernel booted. However,
kernel-4.5.0-300.fc24 hangs in boot again. Was the workaround fix removed?

I'm testing on a PCDuino3 Nano Lite (Allwinner A20).

> Disble ARM_PATCH_IDIV as a work around to fix rhbz 1303147
> 
> in kernel-4.5.0-0.rc7.git0.2.fc24, and that kernel booted. However,
> kernel-4.5.0-300.fc24 hangs in boot again. Was the workaround fix removed?

Boots fine on my CubieTruck which is also a AllWinner A20, but there does appear to be an issue with the NIC, which while a regression I'll look into, is completely unrelated to this.

This issue is solved upstream and touched A7/A15/A17 cores only. Workaround in kernel config was done.

We will close it when all pieces land in Fedora.

For other kernel issues please open new bugs.

Hi Peter,

(In reply to Peter Robinson from comment #33)
> > Disble ARM_PATCH_IDIV as a work around to fix rhbz 1303147
> > 
> > in kernel-4.5.0-0.rc7.git0.2.fc24, and that kernel booted. However,
> > kernel-4.5.0-300.fc24 hangs in boot again. Was the workaround fix removed?
> 
> Boots fine on my CubieTruck which is also a AllWinner A20, but there does
> appear to be an issue with the NIC, which while a regression I'll look into,
> is completely unrelated to this.

The NIC not working in u-boot is a known issue. I've a pretty good idea how to fix this, it should work in the kernel but if you're tftp booting that is not of any help.

Unfortunately I did not realize that u-boot has moved from a 3 month release schedule to a 2 month schedule, otherwise I would have prioritized fixing this. Once I've this fixed I'll send you a mail with 2 sunxi bug-fix patches (this one and another one) to add to Fedora's u-boot v2016.03 release (which I thought would be v2016.04 giving me more time).

Regards,

Hans

> The NIC not working in u-boot is a known issue. I've a pretty good idea how
> to fix this, it should work in the kernel but if you're tftp booting that is
> not of any help.

No, this is not working in the kernel. Nothing to do with u-boot, I'm aware of those issues, I'm on the u-boot mailing list.

> Unfortunately I did not realize that u-boot has moved from a 3 month release
> schedule to a 2 month schedule, otherwise I would have prioritized fixing

It was well documented on the u-boot mailing list.

> this. Once I've this fixed I'll send you a mail with 2 sunxi bug-fix patches
> (this one and another one) to add to Fedora's u-boot v2016.03 release (which
> I thought would be v2016.04 giving me more time).

Sure, or I'm happy to grab them from the u-boot list/patworks too.

That said, this is not the location to discuss any of the above, it's off topic.

(In reply to Marcin Juszkiewicz from comment #21)
> According to gcc docs at
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html this should be
> equal to -O1:
> 
> -O0 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments ...

No, you missed the part that says:

"Most optimizations are only enabled if an -O level is set on the command line. Otherwise they are disabled, even if individual optimization flags are specified."

i.e. -O0 disables all optimizations, you can't turn individual ones on.

https://gcc.gnu.org/wiki/FAQ#optimization-options

I built 4.5 kernel with IDIV enabled using gcc 6.0.0-16 (which has solution merged).

Kernel booted fine.


(In reply to Jonathan Wakely from comment #37)

> No, you missed the part that says:

Thanks. Will remember for future.

(In reply to Peter Robinson from comment #36)
> > The NIC not working in u-boot is a known issue. I've a pretty good idea how
> > to fix this, it should work in the kernel but if you're tftp booting that is
> > not of any help.
> 
> No, this is not working in the kernel. Nothing to do with u-boot, I'm aware
> of those issues, I'm on the u-boot mailing list.
> 
> > Unfortunately I did not realize that u-boot has moved from a 3 month release
> > schedule to a 2 month schedule, otherwise I would have prioritized fixing
> 
> It was well documented on the u-boot mailing list.
> 
> > this. Once I've this fixed I'll send you a mail with 2 sunxi bug-fix patches
> > (this one and another one) to add to Fedora's u-boot v2016.03 release (which
> > I thought would be v2016.04 giving me more time).
> 
> Sure, or I'm happy to grab them from the u-boot list/patworks too.
> 
> That said, this is not the location to discuss any of the above, it's off
> topic.

Proposed as a Blocker for 24-alpha by Fedora user lbrabec using the blocker tracking app because:

 This bug clearly violates alpha criterion:

Initialization requirements

"Release-blocking images must boot" (All release-blocking images must boot in their supported configurations.) and "Release-blocking ARM disk images must boot to the initial-setup utility".

I got stuck again on "Starting kernel ...", tested on Banana Pi with Fedora-Minimal-armhfp-24_Alpha-5-sda.raw.xz (kernel 4.5.0-0.rc7.git0.2.fc24).

I propose this because Banana Pi is a common board as well as are AllWinner SoCs (even though it boots on CubieTruck, as said in comment #37).

> I got stuck again on "Starting kernel ...", tested on Banana Pi with
> Fedora-Minimal-armhfp-24_Alpha-5-sda.raw.xz (kernel 4.5.0-0.rc7.git0.2.fc24).

That kernel already has this fix, this is not the same problem. Please provide details on how you flashed the image in a new BZ. 

> I propose this because Banana Pi is a common board as well as are AllWinner
> SoCs (even though it boots on CubieTruck, as said in comment #37).

We don't block a release on individual devices. The issue you're seeing is not this one. Please open another bug.