Date: Sat, 07 Jan 2012 21:15:58 -0500 From: Greg Ansley <gja@ansley.com> To: freebsd-arm@freebsd.org Subject: Re: porting freebsd to at91sam9g45 ( SBC6045 board) Message-ID: <4F08FC5E.3060504@ansley.com> In-Reply-To: <CABkKHSYtgOkbdzSCnFhjr3WTPaB21DqWzOqkouKtBw0mMRFjpQ@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms050700090603030808010601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable AT91_DBGU_BASE and AT91SAM9G20_BASE are set to 0xD0000000 even though phy= sical base address for Internal Peripherals for the sam9g20 is 0xF0000000 because th= at is where they are mapped to in kernel VM. Contrary to the comment at the top of the declaration of at91_devmap in a= t91_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. This was a choice may be someone before I added the AT91SAMG20 support an= d I did not have a compelling reason to change it and did not what to try to figure o= ut if there would be any unforeseen consequences if I did. So if you do change choose to change it you are going to need to change t= he 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! Greg 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 c= ode >> should be the same, maybe the way to retrieve the amount of memory cha= nged, >> 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 s= tuff to >> enable the DBGU port ? >> >> Regards, >> >> Olivier >> > > > > ok, so I spent couple of days to read the code, but it still doesn't wo= rk ;) > > > > > 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 ;) > > > > I will still be very pleased, if you're able to give me a hint about > lines of code which might give trouble. > > > 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" --------------ms050700090603030808010601--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F08FC5E.3060504>