Date: Fri, 21 Feb 2014 12:20:25 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Warner Losh <wlosh@bsdimp.com> Cc: "'freebsd-arm@freebsd.org'" <freebsd-arm@FreeBSD.org> Subject: Re: About FreeBSD support one more mini-pc Message-ID: <1393010425.1145.143.camel@revolution.hippie.lan> In-Reply-To: <C9DDC3CB-B801-42CF-8B82-D9E05A0E3AC5@bsdimp.com> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <CAB3ij4CKpp5hQWeKk5icq6dgxKX%2BtiFLho1TYKc%2BnTbufGzzFA@mail.gmail.com> <FD2977C2-7F98-4B48-81D6-87D2B81BEA78@bsdimp.com> <1392842988.1145.50.camel@revolution.hippie.lan> <CAB3ij4CHPjAspW%2BjDDOiG2bBsFZ6a5f3P9LbyDAcfxq3BYTLyw@mail.gmail.com> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> <1392925514.1145.68.camel@revolution.hippie.lan> <C9DDC3CB-B801-42CF-8B82-D9E05A0E3AC5@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2014-02-21 at 11:53 -0700, Warner Losh wrote: > On Feb 20, 2014, at 12:45 PM, Ian Lepore wrote: >=20 > > On Thu, 2014-02-20 at 19:08 +0000, Wei=DF, J=FCrgen wrote: > >>> -----Original Message----- > >>> From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freeb= sd.org] On Behalf Of > >>> Ian Lepore > >>> Sent: Thursday, February 20, 2014 5:04 AM > >>> To: Tom Everett > >>> Cc: freebsd-arm@freebsd.org > >>> Subject: Re: About FreeBSD support one more mini-pc > >>>=20 > >>> On Wed, 2014-02-19 at 16:12 -0700, Ian Lepore wrote: > >>>> On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: > >>>>> Hey Ian, i am just about to ask for a pull from my repo with a wo= rking > >>>>> ubldr for wandboard, if you wanted to take a look: > >>>>>=20 > >>>>> https://github.com/teverett/crochet- > >>> freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > >>>>>=20 > >>>>=20 > >>>> My problem isn't with u-boot, it's in the ubldr->kernel handoff. = I'm > >>>> using u-boot-2014.01 these days and it needs no patching other tha= n to > >>>> the wandboard config.h to turn on API and USB and a few other hand= y > >>>> things. But when I boot, sometimes it works but more often it goe= s like > >>>> this: > >>>>=20 > [...]=20 > >>>> And it hangs there forever. The 'a' I just added, that shows me t= hat it > >>>> gets into the kernel, I print that 'a' from the first few instruct= ions > >>>> of locore.S. > >>>=20 > >>> Follow up on this... it is because I'm using a newer u-boot that ha= s the > >>> dcache enabled by default. If I use the "dcache off" command to di= sable > >>> it, it boots perfectly every time. If I leave the cache enabled it > >>> fails to boot most of the time with symptoms that pretty much exact= ly > >>> match stale data in the caches. > >>>=20 > >>> We enable the MMU in locore.S without invalidating old cache conten= ts > >>> first, and that appears to be a bad thing. > >>>=20 > >>> -- Ian > >>>=20 > >>=20 > >> Hm, I use an u-boot version from early December, which has already > >> enabled the L1 Dcache. I did not experience any problems with that > >> version. On Jan 29th code was committed to the u-boot repository to > >> enable the L2 cache. I have not checked that version yet. > >>=20 > >> But without a Dcache invalidate, I had problems to start the second > >> core. > >=20 > > I think it is the enabling of the L2 cache that's causing the problem= , > > because I added your code for invalidating L1 idcache to the first > > processor startup path, and that didn't help. =20 > >=20 > > Flushing the L2 very early in startup is problematic, because we don'= t > > know its register addresses until we can read the fdt data (we don't > > even know what kind of l2 it is), and processing fdt while still runn= ing > > in physical address mode with only pc-relative addressing allowed is > > more or less impossible. >=20 > Do we have the tools to find out at least the kernel part of memory? We= know the PA and VA of kernel area, and symbols like start and end would = be enough to bound it, no? At least that would get us up and running to t= he point where we can parse the FDT to get its data... Or is there someth= ing more subtle afoot here.... The problem is that until the MMU is turned on we can't access normal data, bss, or even call a named function. You can only run position- independant code, and that doesn't mean PLT and GOT stuff, it means you can only get the address of something as an offset from the current PC. The FDT code isn't amenable to running like that. However, I think the suggestion offered by Juergen is a good one: if the MMU is on at entry, then our locore.S code needs to treat it as a mapping (set ttb) change and do the cache maintenance sequences you would do for that, as opposed to the sequences required to turn it on for the first time. Hopefully that's all that's needed and the L2 cache isn't involved in the problem. I'm going to give that a try this weekend. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1393010425.1145.143.camel>