On Wed, Jul 6, 2011 at 12:45 AM, Drasko DRASKOVIC
<drasko.drasko...@gmail.com> wrote:
> On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky <skochin...@mail.ru> wrote:
>> Hello Drasko,
>>
>> Wednesday, July 6, 2011, 12:00:11 AM, you wrote:
>>
>>>> DD> On the first look, this can be accomplished by reading CP0 PRId
>>>> DD> register, but Revision field is not quite well explained.
>>>> DD> I have no idea how to obtain info if the proc is MIPS32/64 Rev2
>>>> compliant.
>>>>
>>>> You should use the Config register (CP0 Register 16). AT field (bits
>>>> 14:13) tells if it's MIPS32 or MIPS64, and AR (12:10) is the release.
>>
>> DD> Hi Igor,
>> DD> thanks, I just took a quick look, and I thought that CP0 PRId would be
>> DD> more appropriate. I saw that bits 7:0 encode the release, but I did
>> DD> not get the codes - they are not well explained in the doc.
>>
>> I would expect that too, but it's not the case, apparently. Bits 7:0
>> is the manufacturer-specific chip revision ID, not the ISA release.
>>
>> DD> Maybe CP0 Config would be a better place to look, though naming is not
>> DD> suggestive - Config is used to configure your CPU (it should be RW)
>> DD> and ID is where you want to read Read Only information...
>>
>> Actually, most of the fields in Config are read-only. Not very
>> logical but that's how it is.
Yes, not very logical, but actually it seems to be quite fine -
because in the same config reg, CP0 CONFIG0, we find K0, KU and K23
field which tel us reachability of KUSG, KSEG0 and KSEG23
respectively. This is good, because it saves us from another CP0 read
(which must be done by executing miniprogram).
I did some progress implementing all these selections and
mips32_cp0_read/write() functions and I am in the process of testing -
so far so good.
I just wanted to verify one thing : how we exactly discover which
segment we should treat (which segment we are in) ?
What I am currently doing in the mips32_pracc_write_mem, which has a
signature like this :
int mips32_pracc_write_mem(struct mips_ejtag *ejtag_info, uint32_t
addr, int size, int count, void *buf)
is
/**
* If we are in the cachable regoion and cache is activated,
* we must clean D$ + invalidate I$ after we did the write,
* so that changes do not continue to live only in D$, but to be
* replicated in I$ also (maybe we wrote the istructions)
*/
uint32_t conf = 0;
int cached = 0;
mips32_cp0_read(ejtag_info, &conf, 16, 0);
switch (KSEGX(addr))
{
case KUSEG:
cached = (conf & MIPS32_CONFIG0_KU_MASK) >>
MIPS32_CONFIG0_KU_SHIFT;
break;
case KSEG0 :
cached = (conf & MIPS32_CONFIG0_K0_MASK) >>
MIPS32_CONFIG0_K0_SHIFT;
break;
case KSEG1:
/* uncachable segment - nothing to do */
break;
case KSEG2:
case KSEG3:
cached = (conf & MIPS32_CONFIG0_K23_MASK) >>
MIPS32_CONFIG0_K23_SHIFT;
break;
default:
/* what ? */
break;
}
where I borrowed KSEGX(addr) macro from Linux :
/** Returns the kernel segment base of a given address */
#define KSEGX(a) ((a) & 0xe0000000)
So, as you see, for segment discovery I use addr variable, but that is
the write destination address. Can it be in the different segment that
the one from we are currently in ?
What should I look for to discover appropriate segment of execution,
so I can look for the appropriate cacheability flags (KU, K0 or K23) ?
BR,
Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
