That diff makes my Banana Pi R1 and someone else’s PCduino boot up without issues.
My u-boot is self-compiled from current u-boot sources with the Lamobo R1 default config. I have not enabled any legacy options. The PCduino’s u-boot seems to be vendor supplied. Imho this diff should go in. Patrick > Am 13.08.2015 um 11:48 schrieb Jonathan Gray <j...@jsg.id.au>: > > On Thu, Aug 13, 2015 at 09:58:22AM +0200, Leonardo Guardati wrote: >> On Fri, Aug 07, 2015 at 11:03:43AM +0200, Average Joe wrote: >>> I have spent another day trying to get this machine to run OpenBSD >>> but have had no success. Since for some reason the network >>> interface is not working I have resorted to loading the ramdisk image >>> from the USB key: >>> >>> sunxi# fatload usb 0 0x40200000 bsd.rd.SUNXI.umg >>> reading bsd.rd.SUNXI.umg >>> 8026368 bytes read in 434 ms (17.6 MiB/s) >>> sunxi# bootm 0x40200000 >>> ## Booting kernel from Legacy Image at 40200000 ... >>> Image Name: boot >>> Image Type: ARM Linux Kernel Image (uncompressed) >>> Data Size: 8026304 Bytes = 7.7 MiB >>> Load Address: 40300000 >>> Entry Point: 40300000 >>> Verifying Checksum ... OK >>> Loading Kernel Image ... OK >>> >>> Starting kernel ... >>> >>> after which the system hangs indefinitely. u-boot version is >>> mainline 2015.07 and I am trying to load an OpenBSD snapshot. >>> >>> Kind regards, >>> Viktor >>> >> >> I was having the same problem with a pcDuino-3-Nano. >> >> The problem was solved adding a configuration option to the menuconfig >> of u-boot: make menuconfig >> >> "ARM Architecture" -> "Enable workarounds for booting old kernels" >> >> then: >> >> $ make CROSS_COMPILE=arm-linux-gnueabihf- >> >> and then adding again the new u-boot-sunxi-with-spl.bin to the miniroot. > > It is interesting that OLD_SUNXI_KERNEL_COMPAT isn't related > to atags/dtb setup but rather pll configuration. > > It looks like the sunxi code in the kernel should change it's > handling of pll5/pll6 to be compatible with newer u-boot. > > u-boot also changes to board id to set bit 28 if OLD_SUNXI_KERNEL_COMPAT > is not set. In which case none of the devices in the kernel will > attach as they are all keyed off that value. So it seems at a minimum > we should mask the board id with 0x0fffffff. I would be curious > to see what happens when running a recent u-boot and the following: > > Index: armv7_machdep.c > =================================================================== > RCS file: /cvs/src/sys/arch/armv7/armv7/armv7_machdep.c,v > retrieving revision 1.24 > diff -u -p -r1.24 armv7_machdep.c > --- armv7_machdep.c 19 May 2015 03:30:54 -0000 1.24 > +++ armv7_machdep.c 13 Aug 2015 09:36:53 -0000 > @@ -397,6 +397,12 @@ initarm(void *arg0, void *arg1, void *ar > bus_space_handle_t *); > > board_id = (uint32_t)arg1; > + /* > + * u-boot has decided the top four bits are > + * 'compatibility revision' for sunxi > + */ > + if (board_id != 0xffffffff) > + board_id &= 0x0fffffff; > > /* > * Heads up ... Setup the CPU / MMU / TLB functions
