Skip site navigation (1)Skip section navigation (2)
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>