Bug 1308355

If it stops working here's how to debug it with earlyprintk:

-# CONFIG_DEBUG_LL is not set
+CONFIG_DEBUG_LL=y
+# CONFIG_DEBUG_BCM2835 is not set
+CONFIG_DEBUG_BCM2836=y
+CONFIG_DEBUG_LL_INCLUDE="debug/pl01x.S"
+CONFIG_DEBUG_UART_PL01X=y
+CONFIG_DEBUG_UART_PHYS=0x3f201000
+CONFIG_DEBUG_UART_VIRT=0xf0201000
+CONFIG_DEBUG_UNCOMPRESS=y
+CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
+CONFIG_EARLY_PRINTK=y
+# CONFIG_SERIAL_SAMSUNG_DEBUG is not set

dmesg: http://paste.fedoraproject.org/322586/54773521/

I'm already working on this

> Please enable CONFIG_BCM2835. The Raspberry Pi 2 support is now good enough
> to boot multi-user.

"good enough" might be a problem, when this gets enabled I want decent support for video/keyboard etc because people generally don't understand serial consoles and the queries for "this doesn't work" support are overwhelming.

> 1.) The kernel compiled with Rawhide toolchain panicks while initializing
> percpu memory. This might be a GCC6 toolchain bug; I just have no other ARM7
> board to verify. A build in Fedora 23 buildroot works fine.

That's a pretty big nitpick, it's also one we're tracking in 1303147
 
> 2.) The video output is not there. Uboot doesn't set up the simplefb
> properly yet and the VC4 devicetree bindings have not been accepted into
> mainline. The serial output works fine though.

:-(

> 3.) The uboot loads the FDT and initrd near the top of the memory, where the
> kernel can't access it (since it seems to overlap the vmalloc space). The
> uboot fixes are pending:

It's an issue with a lot of boards with over 512Mb of RAM and should be fixed in u-boot, I know Stephen accepted a patch for at least the FDT for this.

(In reply to Peter Robinson from comment #4)
> > Please enable CONFIG_BCM2835. The Raspberry Pi 2 support is now good enough
> > to boot multi-user.
> 
> "good enough" might be a problem, when this gets enabled I want decent
> support for video/keyboard etc because people generally don't understand
> serial consoles and the queries for "this doesn't work" support are
> overwhelming.

Understood. Would missing out-of-box video be a blocker for enabling it in kernel? (What if Fedora didn't announce/document that Raspberry Pi is supported, but would make it possible for a remix to exist without a need for a separate kernel?)

> > 1.) The kernel compiled with Rawhide toolchain panicks while initializing
> > percpu memory. This might be a GCC6 toolchain bug; I just have no other ARM7
> > board to verify. A build in Fedora 23 buildroot works fine.
> 
> That's a pretty big nitpick, it's also one we're tracking in 1303147
>  
> > 2.) The video output is not there. Uboot doesn't set up the simplefb
> > properly yet and the VC4 devicetree bindings have not been accepted into
> > mainline. The serial output works fine though.
> 
> :-(

Would simplefb be sufficient for Fedora to enable the Raspberry Pi support? 3D doesn't really work well in Raspbian and noone seems to really mind.

> > 3.) The uboot loads the FDT and initrd near the top of the memory, where the
> > kernel can't access it (since it seems to overlap the vmalloc space). The
> > uboot fixes are pending:
> 
> It's an issue with a lot of boards with over 512Mb of RAM and should be
> fixed in u-boot, I know Stephen accepted a patch for at least the FDT for
> this.

Yes, and the initrd part got his ack too.

With the current rc2 uboot-tools the simplefb works fine (presumably due to 1382648b6be).