Date: Thu, 15 Dec 2016 21:01:15 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Ian Lepore <ian@freebsd.org> Cc: Nicolae-Alexandru Ivan <alexnivan@gmail.com>, freebsd-arm@freebsd.org Subject: Re: Cubieboard2 with custom bootloader Message-ID: <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> In-Reply-To: <1481831623.1972.24.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > >=20 > > >=20 > > > On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: > > > >=20 > > > > On Thu, 15 Dec 2016 14:26:48 +0200 > > > > Nicolae-Alexandru Ivan <alexnivan@gmail.com> wrote: > > > >=20 > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > =A0For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 > > > > > > import > > > > > > (well only ubldr.bin for me ...) > > > > > > =A0For 3 and 4 I've never tested booting kernel directly, I'll > > > > > > try > > > > > > that. > > > > > > =A0Does 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. > > > > >=20 > > > > > #FDT > > > > > options FDT > > > > > options FDT_DTB_STATIC > > > > > makeoptions FDT_DTS_FILE=3Dcubieboard2.dts > > > > =A0Oh I might now, my patches introduce a FreeBSD option for uboot > > > > that > > > > disable the dcache while it's strictly disable in the ports. > > > > =A0Do a gmake menuconfig in uboot before compiling but after gmake > > > > cubieboard2_defconfig to enable this. > > > >=20 > > > 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. =A0The 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). =A0For freebsd the needed cache > > > ops > > > must be patched into two places, the bootelf path and the go path. > > >=20 > > > -- Ian > > =A0Well the dcache has been strictly disabled in most of our port for > > quite some times now. > > =A0I'll run some test so see if it's still needed and update the port > > if > > it's not. > > =A0And it raise a question: Why couldn't we flush the dcache at the > > start > > of ubldr for arm if it's needed ? > > =A0I'm gonna try to upstream by "FreeBSD config" v2 patches soon so I > > want to do it right. > >=20 >=20 > 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. =A0See 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 ? --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161215210115.b224a164cb32abef56b86e7d>