Cubieboard2 with custom bootloader

[Ian Lepore]

On Thu, 2016-12-15 at 19:48 +0100, Emmanuel Vadot wrote:
> On Thu, 15 Dec 2016 09:03:13 -0700
> Ian Lepore <ian at freebsd.org> wrote:
> 
> > 
> > On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote:
> > > 
> > > On Thu, 15 Dec 2016 14:26:48 +0200
> > > Nicolae-Alexandru Ivan <alexnivan at gmail.com> wrote:
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > >  For 1 and 2, as Ganbold said ubldr is broken since clang 3.9
> > > > > import
> > > > > (well only ubldr.bin for me ...)
> > > > >  For 3 and 4 I've never tested booting kernel directly, I'll
> > > > > try
> > > > > that.
> > > > >  Does your kernel have a static dtb compiled in ?
> > > > Yes, we included the device tree in the kernel binary.
> > > > The options below are included in our conf.
> > > > 
> > > > #FDT
> > > > options FDT
> > > > options FDT_DTB_STATIC
> > > > makeoptions FDT_DTS_FILE=cubieboard2.dts
> > >  Oh I might now, my patches introduce a FreeBSD option for uboot
> > > that
> > > disable the dcache while it's strictly disable in the ports.
> > >  Do a gmake menuconfig in uboot before compiling but after gmake
> > > cubieboard2_defconfig to enable this.
> > > 
> > It shouldn't be necessary to disable dcache, but it does need to be
> > flushed before launching ubldr or the kernel; especially, it needs
> > the
> > icache sync'd.  The stock uboot does the needed cache work only in
> > the
> > path that launches linux that has been packaged as an image file
> > (and
> > before launching vxworks I think).  For freebsd the needed cache
> > ops
> > must be patched into two places, the bootelf path and the go path.
> > 
> > -- Ian
>  Well the dcache has been strictly disabled in most of our port for
> quite some times now.
>  I'll run some test so see if it's still needed and update the port
> if
> it's not.
>  And it raise a question: Why couldn't we flush the dcache at the
> start
> of ubldr for arm if it's needed ?
>  I'm gonna try to upstream by "FreeBSD config" v2 patches soon so I
> want to do it right.
> 

Dcache has been enabled in the uboot ports I was taking care of for a
long time; any of those ports have the needed patches for cache
maintenance before launching ubldr or the kernel.  See for example u-
boot-rpi, the patches for cmd_boot and cmd_elf.

The cache maintenance must be done *before* jumping to the ubldr or
kernel entry point, or else it's possible to jump to bad code (stale
cached data) that hangs or crashes.

-- Ian