[PATCH 05/14] at91: use structure to store the current soc
ryan at bluewatersys.com
Mon May 2 16:38:36 EDT 2011
On 05/03/2011 08:24 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> So I don't see how you can "detect" the CPU without first knowing
>>>> which CPU and therefore where the DBGU register is anyway.
>>>> And probing different addresses for a value is not an acceptable solution.
>>> we have 2 different register 0xfffff200 and 0xffffee00
>>> which are the DBGU or the PIOA
>>> and on the PIOA at the offset 0x40 if you try to read the cpu will always
>>> return 0x0, and have no effect on the soc
>>> so I do not think there is a big issue to read 2 register to detect the soc
>> This does rely on Atmel not making another soc which has the DBGU at an
>> address which does cause a conflict (low possibility, but would be very
>> annoying). It's also really ugly to read random registers until we get
>> the one we want.
>> However, I still do not see what is wrong with the current approach of
>> the boards explicitly specifying the soc type. The correct soc/cpu type
>> can already be determined without changing the code. So why are we
>> changing the code?
> Because some hardware design architecture such as CPU module do allow to have
> the SAME board with different SOC. So have one machine ID per combinaison because
> we just change the soc is a non-sense.
You haven't named such a piece of hardware yet. We have boards like our
own Snapper 9260/9G20 where the same mach-type is used for two boards,
one with a SAM9260 and the other with a SAM9G20. Because these are
variants of the same soc we know that the DBGU is at the same address on
both and so we can read the cpuid registers to determine which board it is.
Can you give me an example of a mach-type which is used for two or more
boards that cannot be differentiated this way?
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
More information about the linux-arm-kernel