Cubieboard2 with custom bootloader

[Ian Lepore]

On Thu, 2016-12-15 at 21:01 +0100, Emmanuel Vadot wrote:
> On Thu, 15 Dec 2016 12:53:43 -0700
> Ian Lepore <ian at freebsd.org> wrote:
> 
> > 
> > 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.
>  Yes I've seen that, I'll confirm that it isn't needed on Allwinner
> and
> do some patch.
> 
> > 
> > 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.
>  Ok, so newbie question on cache here, why does Linux doesn't need
> this ? and what can we do (if possible) to avoid the need of cache
> flush ?
> 

I should mention, btw, that enabling the cache does make a huge
difference.  For a wandboard with caches disabled, loading and
launching the kernel takes 8 or 9 seconds, with dcache enabled it's
less than 1 second.

-- Ian