porting freebsd to at91sam9g45 ( SBC6045 board)

[Greg Ansley]

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.

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!

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"