From owner-freebsd-arm@FreeBSD.ORG Thu Feb 20 19:09:11 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 70AA897C; Thu, 20 Feb 2014 19:09:11 +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 7F27B13AF; Thu, 20 Feb 2014 19:09:10 +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=1392923351; x=1424459351; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j9+KBknJaV1kQcLkyGxWWPzaVxi9QeU+95eqM9cWXHI=; b=AwIhrEqrX5Q1fNZ4gaFjFeYRDVX31FAcbv8pqTQrh4Rt+Rd4pC59cxN+ pCyKL8riD2ODfyrs3VeBEZm2B2YtDiJC5ELlLYfujKFtoBNUVTa6Es0O2 vSYtv3i5gLWOUMLjrdwlVNh0rK2szxEvLKOkp7uu6sUY2JCkescKNusAN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAKpRBlMKXgZY/2dsb2JhbABZgmVZV8AOgSZ0giUBAQUnUgwEAgEIEQQBAQEnBzIUCQgCBAEJBAUIh30BDM4lEwSOZAcGhDIEiRCVYotigy2CKg X-IPAS-Result: AqIEAKpRBlMKXgZY/2dsb2JhbABZgmVZV8AOgSZ0giUBAQUnUgwEAgEIEQQBAQEnBzIUCQgCBAEJBAUIh30BDM4lEwSOZAcGhDIEiRCVYotigy2CKg Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 20 Feb 2014 20:09:07 +0100 Received: from e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) 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 20:08:15 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 20 Feb 2014 20:08:03 +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 20:08:03 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ian Lepore' , 'Tom Everett' Subject: RE: About FreeBSD support one more mini-pc Thread-Topic: About FreeBSD support one more mini-pc Thread-Index: AQHPLMx2lO8+uVBB/02TkpGpjfhkM5q82ewAgAAfLwCAAAI1AIAAApQAgAAW/YCAABEDAIAAUVUAgAEJdPA= Date: Thu, 20 Feb 2014 19:08:02 +0000 Message-ID: <38db362d34174f70a07c0b9ea39a54c4@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> In-Reply-To: <1392869044.1145.58.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 19:09:11 -0000 > -----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 >=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 workin= g > > > ubldr for wandboard, if you wanted to take a look: > > > > > > https://github.com/teverett/crochet- > freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > > > > > > > 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 than to > > the wandboard config.h to turn on API and USB and a few other handy > > things. But when I boot, sometimes it works but more often it goes lik= e > > this: > > > > U-Boot 2014.01 (Feb 19 2014 - 15:31:16) > > > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > > Reset cause: POR > > Board: Wandboard > > DRAM: 2 GiB > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > In: serial > > Out: serial > > Err: serial > > Net: FEC > > Hit any key to stop autoboot: 0 > > FEC Waiting for PHY auto negotiation to complete... done > > BOOTP broadcast 1 > > *** Unhandled DHCP Option in OFFER/ACK: 69 > > ... > > *** Unhandled DHCP Option in OFFER/ACK: 42 > > DHCP client bound to address 172.22.42.236 > > Using FEC device > > TFTP from server 172.22.42.240; our IP address is 172.22.42.236 > > Filename '/wand/boot/ubldr'. > > Load address: 0x11000000 > > Loading: ############## > > 10.4 MiB/s > > done > > Bytes transferred =3D 195484 (2fb9c hex) > > ## Starting application at 0x11000054 ... > > Consoles: U-Boot console > > Compatible API signature found @8f564028 > > Number of U-Boot devices: 2 > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > (ilepore@revolution.hippie.lan, Wed Feb 19 15:41:25 MST 2014) > > DRAM: 2048MB > > > > Device: disk > > - > > /boot/kernel/kernel text=3D0x42f3d0 data=3D0x31d14+0x2df1c > syms=3D[0x4+0x923b0+0x4+0x6e34d] > > Hit [Enter] to boot immediately, or any other key for command p= rompt. > > Booting [/boot/kernel/kernel]... > > Using DTB compiled into kernel. > > Kernel entry at 0x12000100... > > Kernel args: (null) > > a > > > > And it hangs there forever. The 'a' I just added, that shows me that i= t > > gets into the kernel, I print that 'a' from the first few instructions > > of locore.S. >=20 > 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. >=20 > We enable the MMU in locore.S without invalidating old cache contents > first, and that appears to be a bad thing. >=20 > -- Ian >=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. But without a Dcache invalidate, I had problems to start the second core. 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