From owner-freebsd-arm@FreeBSD.ORG Thu Feb 20 22:12:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F65AE57; Thu, 20 Feb 2014 22:12:47 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECBE16D4; Thu, 20 Feb 2014 22:12:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1392934368; x=1424470368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4mR9HLTvGmZOANivCaAxRVV5fR+kXSip0cBRLTJNn8k=; b=WMf4XxcP45tt60cX1GcDMqd2hyYpTkCOpZr2s+HFo+P2qN3O4yCocdpr 3pmoCnlUeRYdRjWKwGD3Os5T9xlfLo4d31gFYphTb/pxViWm+0CGSuOPT nkBZccEMww8Bu0CBCi5xAfpzLEpcIoZssay9cTn3L8otCWADsL4I6eQ5t E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAEB9BlMKXgZY/2dsb2JhbABZgmWBMMARgSd0giUBAQQBeQUHBAIBCBEEAQEBJwcyFAkIAgQOBQiHdQgBzTwXjmQHBoQyBIkQlWKLYoMtgio X-IPAS-Result: AqIEAEB9BlMKXgZY/2dsb2JhbABZgmWBMMARgSd0giUBAQQBeQUHBAIBCBEEAQEBJwcyFAkIAgQOBQiHdQgBzTwXjmQHBoQyBIkQlWKLYoMtgio Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 20 Feb 2014 23:12:45 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 20 Feb 2014 23:11:52 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 20 Feb 2014 23:11:51 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238]) by e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238%18]) with mapi id 15.00.0775.031; Thu, 20 Feb 2014 23:11:51 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ian Lepore' Subject: RE: About FreeBSD support one more mini-pc Thread-Topic: About FreeBSD support one more mini-pc Thread-Index: AQHPLMx2lO8+uVBB/02TkpGpjfhkM5q82ewAgAAfLwCAAAI1AIAAApQAgAAW/YCAABEDAIAAUVUAgAEJdPD///2CAIAALfMg Date: Thu, 20 Feb 2014 22:11:51 +0000 Message-ID: <302a70c418f04def935dd421aa6d968d@e15be-03.zdv.Uni-Mainz.DE> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <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> In-Reply-To: <1392925514.1145.68.camel@revolution.hippie.lan> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 22:12:47 -0000 > -----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