Date: Thu, 15 Dec 2016 13:06:46 -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: <1481832406.1972.29.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 ? > Linux does need it... that's what I said originally: u-boot only does the necessary cache maintaince when launching the linux kernel using the bootm family of commands that handle zImage type files (look for a symbol in uboot named "prepare_for_linux()" or something close to that spelling). For the other flavors of boot command (bootelf, go, maybe others) it does nothing, it just jumps to the entry point, often hanging when it does. The prepare_for_linux() code does some things that we don't need, so when I wrote the patches for bootelf and go I made them just call the needed cache cleaning routines directly. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1481832406.1972.29.camel>