Date: Fri, 09 Mar 2018 16:23:34 -0700 From: Ian Lepore <ian@freebsd.org> To: Eddy Petri <eddy.petrisor@gmail.com>, Steve Wills <swills@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: No arch specific invalidate_icache_all available! Message-ID: <1520637814.84937.93.camel@freebsd.org> In-Reply-To: <CAK0XTWfGAqUyAXvKETaU44tmpvEa-%2B2N2=GbuHS0ycBBPWy3XA@mail.gmail.com> References: <0ea2ec57-da6f-c8df-aaf4-d986b56a8ecd@FreeBSD.org> <CAK0XTWfGAqUyAXvKETaU44tmpvEa-%2B2N2=GbuHS0ycBBPWy3XA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2018-03-10 at 01:05 +0200, Eddy Petrior wrote: > 2018-03-09 20:56 GMT+02:00 Steve Wills <swills@freebsd.org>: > > > > Hi, > Hi, > > > > > > > Trying to boot r330240 on my Raspberry Pi B, I'm getting: > > > > Booting [/boot/kernel/kernel]... > > /boot/dtb/bcm2835-rpi-b-rev2.dtb size=0x3366 > > Loaded DTB from file 'bcm2835-rpi-b-rev2.dtb'. > > Kernel entry at 0x1200100... > > No arch specific invalidate_icache_all available! > > Kernel args: (null) > > > > Then it goes back to U-Boot. Any ideas on what's wrong here? > Without claiming to know the FreeBSD code in any reasonable way, but > using my experiance with low level stuff, it seems the memory > management system expects a platform specific implementation of the" > invalidate all instruction caches" functionality. > Typically this is needed in situations where you might expect the > cached results you might have loaded are possibly out of sync relative > to the main memory contents. > > In some cases, it is just a good defensive programming (e.g. > invalidating caches during the initalization sequence would be done > just to make sure there is no funny business going on and the code > from the main memory will be executed. > > At this stage, during initilization, the invalidation might not be > necessary and the message in question could generated because there is > someintial inventory of necessary serivices and APIs and thati > failed. > > > I expect someone with more intimate knowledge of this exact section of > the FreeBSD code could provide more info, because, frankly, you made > me curious. > It sounds to me like the wrong uboot is in use, like the one for the armv7 flavor of rpi being used on the armv6 hardware (v6 and v7 require different cache maintenance operations). U-boot runs with caches enabled, so it definitely needs to flush both the dcache and the icache before jumping to the code it just loaded. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1520637814.84937.93.camel>