Date: Sat, 7 Jan 2012 19:59:18 -0700 From: Warner Losh <imp@bsdimp.com> To: Greg Ansley <gja@ansley.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: porting freebsd to at91sam9g45 ( SBC6045 board) Message-ID: <BFE291AA-9C9D-40F4-A6A5-C6E7F550D638@bsdimp.com> In-Reply-To: <4F08FC5E.3060504@ansley.com> References: <CABkKHSbVEi6-0L%2BTX4tQSV2pa1Kp1RtkVKKPDe1rOF3oatfGGQ@mail.gmail.com> <20120103104814.GA95533@ci0.org> <CABkKHSZear9Mbky=8DAe_uk5Jz%2BJZyhT6Zaix27UtL3YOCnczw@mail.gmail.com> <20120103160717.GA1744@ci0.org> <CABkKHSaiUmHo5LU32%2B%2BjShE8hQ2AFP8ep%2B7zkW12PV7LKrwqsw@mail.gmail.com> <CABkKHSYtgOkbdzSCnFhjr3WTPaB21DqWzOqkouKtBw0mMRFjpQ@mail.gmail.com> <4F08FC5E.3060504@ansley.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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<mlfbsd@ci0.org> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFE291AA-9C9D-40F4-A6A5-C6E7F550D638>