From owner-freebsd-arm@FreeBSD.ORG Sun Jan 8 03:02:19 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FC171065678 for ; Sun, 8 Jan 2012 03:02:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9828B8FC15 for ; Sun, 8 Jan 2012 03:02:18 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q082xIu7078442 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 7 Jan 2012 19:59:18 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4F08FC5E.3060504@ansley.com> Date: Sat, 7 Jan 2012 19:59:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120103104814.GA95533@ci0.org> <20120103160717.GA1744@ci0.org> <4F08FC5E.3060504@ansley.com> To: Greg Ansley X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 07 Jan 2012 19:59:18 -0700 (MST) Cc: freebsd-arm@FreeBSD.org Subject: Re: porting freebsd to at91sam9g45 ( SBC6045 board) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 03:02:19 -0000 On Jan 7, 2012, at 7:15 PM, Greg Ansley wrote: > AT91_DBGU_BASE and AT91SAM9G20_BASE are set to 0xD0000000 even though = physical base > address for Internal Peripherals for the sam9g20 is 0xF0000000 because = that is > where they are mapped to in kernel VM. >=20 > Contrary to the comment at the top of the declaration of at91_devmap = in at91_machdep.c If > you look closely at the very first value, it is 0xdff00000 not = 0xfff00000 resulting in the > peripherals being mapped to 0x10000000 lower than their physical = values. >=20 > This was a choice may be someone before I added the AT91SAMG20 support = and I did not > have a compelling reason to change it and did not what to try to = figure out > if there would be any unforeseen consequences if I did. This value originally was 0xf0000000, but was changed to 0xd0000000 = during the development of the AT91RM9200 support. We changed this = because we were seeing some aliasing problems with 1:1 mapping that = resulted in instability in the system under load. Once we made this = change, all those problems went away. Ollivier Houchard spotted the = issue while he and I were debugging some strange crashes. > So if you do change choose to change it you are going to need to = change the AT91xxx_BASE > values for all the different SOCs we currently support. Don't forget = get someone to test > on the other chips if you do! And test it under load. Warner > Greg >=20 > On 1/7/12 7:40 PM, Aleksander Dutkowski wrote: >> On Tue, Jan 3, 2012 at 5:07 PM, Olivier Houchard = wrote: >>> Hmm, I don't know the SAM9G45, but reading the linux stuff, the UART = code >>> should be the same, maybe the way to retrieve the amount of memory = changed, >>> and at91_ramsize() is wrong for your CPU, you can test it quickly by >>> hardcoding the ram size in at91_ramsize(), or maybe there's some new = stuff to >>> enable the DBGU port ? >>>=20 >>> Regards, >>>=20 >>> Olivier >>>=20 >>=20 >>=20 >>=20 >> ok, so I spent couple of days to read the code, but it still doesn't = work ;) >>=20 >>=20 >>=20 >>=20 >> I dont know, why AT91_DBGU_BASE and especially AT91SAM9G20_BASE is = set >> to 0xD0000000 when base for Internal Peripherals for sam9g20 is >> 0xF0000000 (I've fixed it already). >> Ive also changed AT91SAM9G20_DBGU_BASE to proper value and all >> at91_cpu_is() function calls. >> Seems that sam9g45 doesn't have SDRAMC, so I've hardcoded >> at91_ramsize(), just like you've said. >> but in sys/arm/at91/at91sam9g20.c:238, the author says that it has to >> be changed for other CPUs. >> Seems that there is much more work to do ;) >>=20 >>=20 >>=20 >> I will still be very pleased, if you're able to give me a hint about >> lines of code which might give trouble. >>=20 >>=20 >> Regards, >> Aleksander >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20