porting freebsd to at91sam9g45 ( SBC6045 board)

[Warner Losh]

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.
> 
> 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.
> 
> 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
> 
> On 1/7/12 7:40 PM, Aleksander Dutkowski wrote:
>> On Tue, Jan 3, 2012 at 5:07 PM, Olivier Houchard<mlfbsd at 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 ?
>>> 
>>> Regards,
>>> 
>>> Olivier
>>> 
>> 
>> 
>> 
>> ok, so I spent couple of days to read the code, but it still doesn't work ;)
>> 
>> 
>> 
>> 
>> 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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>