From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
Date: Fri, 28 Oct 2011 07:07:37 +0200 [thread overview]
Message-ID: <4EAA3899.2090408@aribaud.net> (raw)
In-Reply-To: <CAPnjgZ160Unujwwaj0XdyZ0GBHd4JxdSS5NH4tWkayUzfPUiGw@mail.gmail.com>
Hi Simon,
Le 28/10/2011 00:46, Simon Glass a ?crit :
> Hi Albert,
>>>>>> 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.
>
> 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.
That's the general idea of what I am asking for: test for actual
conditions when needed rather than assume conditions at build time.
However I don't want to test for ARMv7 architecture, because there is no
reason for *all* ARMv7 cores to fail handling current cp15 init.
What I want here is to test for NVidia Tegra2 AVP (using the
Implementer, Variant, Primary part number and possibly even Revision
fields of MIDR), since you have demonstrated it to not handle the
current cp15 init.
Plus, run-time testing on MIDR could later on allow us to reduce ARM
init code path to a single, common start.S for generic/common ARM init
code, and specific code would be 'switched' into, based on MIDR -- that
could allow for multiple board support in a single binary.
> Regards,
> Simon
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-10-28 5:07 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-13 21:05 [U-Boot] [PATCH 0/9] tegra2: Tidy up boot path Simon Glass
2011-10-13 21:05 ` [U-Boot] [PATCH 1/9] tegra2: Add arch_cpu_init() to fire up Cortex-A9 Simon Glass
2011-10-13 22:52 ` Mike Frysinger
2011-10-13 23:18 ` Simon Glass
2011-10-13 23:34 ` Mike Frysinger
2011-10-14 0:47 ` Simon Glass
2011-10-13 21:05 ` [U-Boot] [PATCH 2/9] tegra2: Simplify tegra_start() boot path Simon Glass
2011-10-13 21:05 ` [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit() Simon Glass
2011-10-21 20:58 ` Albert ARIBAUD
2011-10-21 21:18 ` Simon Glass
2011-10-21 21:43 ` Albert ARIBAUD
2011-10-21 21:54 ` Simon Glass
2011-10-21 22:24 ` Albert ARIBAUD
2011-10-22 5:05 ` Simon Glass
2011-10-22 7:56 ` Albert ARIBAUD
2011-10-22 16:13 ` Simon Glass
2011-10-24 19:34 ` Simon Glass
2011-10-24 20:04 ` Albert ARIBAUD
2011-10-24 20:14 ` Simon Glass
2011-10-24 21:21 ` Albert ARIBAUD
2011-10-25 5:02 ` Simon Glass
2011-10-25 6:41 ` Albert ARIBAUD
2011-10-25 13:44 ` Simon Glass
2011-10-25 21:16 ` Simon Glass
2011-10-27 20:05 ` Albert ARIBAUD
2011-10-27 20:17 ` Simon Glass
2011-10-27 22:39 ` Albert ARIBAUD
2011-10-27 22:46 ` Simon Glass
2011-10-28 1:43 ` Simon Glass
2011-10-28 5:09 ` Albert ARIBAUD
2011-10-29 0:36 ` Simon Glass
2011-10-30 10:16 ` Albert ARIBAUD
2011-10-31 21:44 ` Simon Glass
2011-10-31 22:54 ` Tom Warren
2011-11-05 5:17 ` Simon Glass
2011-11-05 8:09 ` Albert ARIBAUD
2011-11-05 13:36 ` Simon Glass
2011-10-28 5:07 ` Albert ARIBAUD [this message]
2011-11-05 8:17 ` Albert ARIBAUD
2011-11-05 14:00 ` Simon Glass
2011-10-13 21:05 ` [U-Boot] [PATCH 4/9] tegra2: Enable instruction cache Simon Glass
2011-10-13 21:05 ` [U-Boot] [PATCH 5/9] tegra2: Remove unneeded boot code Simon Glass
2011-10-13 21:06 ` [U-Boot] [PATCH 6/9] tegra2: Remove unneeded config option Simon Glass
2011-10-13 21:06 ` [U-Boot] [PATCH 7/9] tegra2: Remove unused low-level Tegra2 UART code Simon Glass
2011-10-13 21:06 ` [U-Boot] [PATCH 8/9] tegra2: Remove unneeded 'dynamic ram size' message Simon Glass
2011-10-13 21:06 ` [U-Boot] [PATCH 9/9] tegra2: Don't use board pointer before it is set up Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EAA3899.2090408@aribaud.net \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox