Date: Thu, 20 Feb 2014 22:11:51 +0000 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= <weiss@uni-mainz.de> To: 'Ian Lepore' <ian@FreeBSD.org> Cc: "'freebsd-arm@freebsd.org'" <freebsd-arm@FreeBSD.org> Subject: RE: About FreeBSD support one more mini-pc Message-ID: <302a70c418f04def935dd421aa6d968d@e15be-03.zdv.Uni-Mainz.DE> In-Reply-To: <1392925514.1145.68.camel@revolution.hippie.lan> 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>
index | next in thread | previous in thread | raw e-mail
> -----Original Message----- > From: Ian Lepore [mailto:ian@FreeBSD.org] > Sent: Thursday, February 20, 2014 8:45 PM > To: Weiß, Jürgen > Cc: 'freebsd-arm@freebsd.org' > Subject: RE: About FreeBSD support one more mini-pc > > On Thu, 2014-02-20 at 19:08 +0000, Weiß, Jürgen wrote: > > > -----Original Message----- > > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd.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 > > > > > > > > And it hangs there forever. The 'a' I just added, that shows me that it > > > > gets into the kernel, I print that 'a' from the first few instructions > > > > of locore.S. > > > > > > Follow up on this... it is because I'm using a newer u-boot that has the > > > dcache enabled by default. If I use the "dcache off" command to disable > > > 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 exactly > > > match stale data in the caches. > > > > > > We enable the MMU in locore.S without invalidating old cache contents > > > first, and that appears to be a bad thing. > > > > > > -- Ian > > > > > > > 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. > > > > But without a Dcache invalidate, I had problems to start the second > > core. > > 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. For the first core you should wbinv the L1 Dcache when changing translations, as it was already invalidated (and enabled) by u-boot or even rom. By only invalidating the Dcache one may lose un"written back" data. The L1 Caches of the other cores are not initialized by u-boot or rom and contain garbage. They must not be written back to avoid corruption of main memory. > 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 running > in physical address mode with only pc-relative addressing allowed is > more or less impossible. > > -- Ian > As a PIPT cache, the L2 cache should be transparent to almost all operations with the exception of DMA. And DMA should be of no concern in early boot. The L2 cache operations are only added to the cpu_functions after the L2 cache is probed and attached. Or do I miss something? Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?302a70c418f04def935dd421aa6d968d>