Date: Thu, 15 Dec 2016 13:09:06 -0700 From: Ian Lepore <ian@freebsd.org> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Nicolae-Alexandru Ivan <alexnivan@gmail.com>, freebsd-arm@freebsd.org Subject: Re: Cubieboard2 with custom bootloader Message-ID: <1481832546.1972.31.camel@freebsd.org> In-Reply-To: <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> References: <CANg1yUsXALko5VvLsyNsHfkA2CDbRX4G_ARgFyjs7ixOo_9KKw@mail.gmail.com> <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <CANg1yUvmK3ti%2BSVXm30GB764SusaDYeKr6SPs5murXXV-8AZVQ@mail.gmail.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <CAPEXxG6Dc33kcy2-jdCF%2BM9XJ5F9XaXpn_U4WT-GaDS=qYNj6w@mail.gmail.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> <1481831623.1972.24.camel@freebsd.org> <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2016-12-15 at 21:01 +0100, Emmanuel Vadot wrote: > On Thu, 15 Dec 2016 12:53:43 -0700 > Ian Lepore <ian@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1481832546.1972.31.camel>