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>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Ian Lepore [mailto:ian@FreeBSD.org] > Sent: Thursday, February 20, 2014 8:45 PM > To: Wei=DF, J=FCrgen > Cc: 'freebsd-arm@freebsd.org' > Subject: RE: About FreeBSD support one more mini-pc >=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@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 th= at it > > > > gets into the kernel, I print that 'a' from the first few instructi= ons > > > > 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 disa= ble > > > 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. >=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. For the first core you should wbinv the L1 Dcache when changing translation= s, as it was already invalidated (and enabled) by u-boot or even rom. By only= =20 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.=20 They must not be written back to avoid corruption of main memory.=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 running > in physical address mode with only pc-relative addressing allowed is > more or less impossible. >=20 > -- Ian >=20 As a PIPT cache, the L2 cache should be transparent to almost all operation= s 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-2= 6407
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?302a70c418f04def935dd421aa6d968d>