Hi Albert,
On Thu, Oct 27, 2011 at 3:46 PM, Simon Glass <s...@chromium.org> wrote:
> Hi Albert,
>
> On Thu, Oct 27, 2011 at 3:39 PM, Albert ARIBAUD
> <albert.u.b...@aribaud.net> wrote:
>> Le 27/10/2011 22:17, Simon Glass a écrit :
>>>
>>> Hi Albert,
>>>
>>> On Thu, Oct 27, 2011 at 1:05 PM, Albert ARIBAUD
>>> <albert.u.b...@aribaud.net> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> Le 25/10/2011 23:16, Simon Glass a écrit :
>>>>
>>>>>> But please think about what you actually want in start.S. Do you
>>>>>> really want an #ifdef TEGRA2 with a check of a SOC register, followed
>>>>>> by a branch around the cp15_init code?
>>>>>
>>>>> ^^^^
>>>>> This is the bit we need to sort out.
>>>>
>>>> Indeed, but I dont want a '#ifdef TEGRA2'. In the worst case I want a 'if
>>>> (!core_is_avp())' by way of an identification register, and in the best
>>>> case, I just want cp15 to be set unconditionally.
>>>
>>> You already have #ifdef TEGRA2 (look at the top of start.S). That is
>>> what I am trying to remove.
>>>
>>> How can I call core_is_avp() on an SOC that isn't Tegra? Can you
>>> please write a little code fragment that I should use in start.S, so
>>> that I can understand what is required here.
>>>
>>>>
>>>>>>>>> According to ARM, coprocessors 14 and 15 should always be supported
>>>>>>>>> from
>>>>>>>>> ARMv6 up. Are you sure the AVP does not have it? If there is a Tegra
>>>>>>>>> specification available, I'd like to have a look at it.
>>>>>>>>
>>>>>>>> Sorry I meant caches/MMU, etc. I should try doing the CP15 cache/MMU
>>>>>>>> init on the AVP and see what happens.
>>>>>>>
>>>>>>> Please do check this. It may be that you can actually write to it from
>>>>>>> AVP
>>>>>>> even though it has no or not all expected effect; and if that is
>>>>>>> confirmed,
>>>>>>> then you don't have to separate the boot paths any more,
>>>>>>
>>>>>> Yes I'm tempted to go with this even if the ARM ARM is silent on the
>>>>>> matter. I will try it out today.
>>>>>
>>>>> Silly me of course it doesn't work - since if the CP15 doesn't have
>>>>> those features then you get undef instruction exception. Please see
>>>>> ^^^ above!
>>>>
>>>> Are you stating a reasoning here or the results of an actual test? What
>>>> causes an undefined instruction exception is the absence of a coprocessor
>>>> to
>>>> handle the instruction, not the presence of a coprocessor which
>>>> incidentally
>>>> cannot perform all of what"s being asked.
>>>
>>> Yes I did test it - it hangs. Would you like me to spend some time to
>>> debug exactly why? I suspect it is an undef instruction, since
>>> executing cache instructions on an ARM7TDMI is dodgy, but I could
>>> check if it would help. But let's assume for now we can't do that!
>>
>> What was the test exactly? Depending on which register of CP15 you try to
>> access, things could be different. Can you test MRC p15,0,<Rt>,c0,c0,0 ?
>> That's the MIDR and it should be always accessible, plus it should have a
>> unique value for each type of core, so it could be used to not write cp15
>> for caches etc from the AVP.
The test was
mrc p15, 0, r0, c0, c0, 0 @ get ID register
and r0, r0, #0xf0000 @ get architecture
cmp r0, #0xf0000 @ check for > ARMv6
movne pc, lr @ else skip cache init
Unfortunately I think it is a plain ARM7TDMI with no CP15.
Regards,
Simon
>
> I'm sure that is fine. So do you want me to add a check that the ID
> shows architecture ARMv7, and then skip the cache code if not? It
> should be safe enough since it is a clear signal that something is not
> right. It would also handle the case where an Cortex-A7 (with a cache)
> is attached.
>
> Regards,
> Simon
>
>>
>>> Regards,
>>> Simon
>>
>> Amicalement,
>> --
>> Albert.
>>
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
