On Wed, Jul 6, 2011 at 9:32 PM, Drasko DRASKOVIC
wrote:
> Open questions are :
> 1) As I mentioned before, is this KSEG discovery good ? Do I get well
> which segment we are (look my previous post on the subject)
> 2) mips32_c0_write() is not used for the moment, so it can not be
> commited to ma
Hi all,
based on the previous discussions about this subject, I came up with this patch.
It :
1) Looks if the segment is cacheable
2) If yes, Adds cache sync via synci, if REV is 2
3) If REV1, it uses "cache" instruction
Now it should work for both Revisions.
I also added mips32_c0_read/write()
On Wed, Jul 6, 2011 at 12:45 AM, Drasko DRASKOVIC
wrote:
> On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky 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 fi
On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky 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 obt
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 sh
2011/7/5 Igor Skochinsky :
> Hello Drasko,
>
> Tuesday, July 5, 2011, 7:01:44 PM, you wrote:
>
> DD> On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver
> wrote:
>>> I think your patch is ok, but would be better if it checks the arch version
>>> and issue a warning about cache writes not supported or
Hello Drasko,
Tuesday, July 5, 2011, 7:01:44 PM, you wrote:
DD> On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver wrote:
>> I think your patch is ok, but would be better if it checks the arch version
>> and issue a warning about cache writes not supported or something along
>> those lines.
DD> On
On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver wrote:
> I think your patch is ok, but would be better if it checks the arch version
> and issue a warning about cache writes not supported or something along
> those lines.
On the first look, this can be accomplished by reading CP0 PRId
register, bu
On 05/07/2011 17:09, Drasko DRASKOVIC wrote:
On Tue, Jul 5, 2011 at 5:32 PM, Spencer Oliver wrote:
After a quick look over i see your patch assumes that synci is
supported by the target - may not be the case.
Hi Spen,
yes, this is true. Otherwise we can re-implement this with "cache"
command,
On Tue, Jul 5, 2011 at 5:32 PM, Spencer Oliver wrote:
> After a quick look over i see your patch assumes that synci is
> supported by the target - may not be the case.
Hi Spen,
yes, this is true. Otherwise we can re-implement this with "cache"
command, but it will not be so nice.
If we decide to
On 5 July 2011 15:44, Drasko DRASKOVIC wrote:
> On Thu, Jun 30, 2011 at 6:25 PM, Drasko DRASKOVIC
> wrote:
>> Now, in case of EJTAG communication implementation in mips32_pracc.c
>> this is not a simple thing to implement. I am currently adding missing
>> opcodes and trying to craft a miniprogram
On Thu, Jun 30, 2011 at 6:25 PM, Drasko DRASKOVIC
wrote:
> Now, in case of EJTAG communication implementation in mips32_pracc.c
> this is not a simple thing to implement. I am currently adding missing
> opcodes and trying to craft a miniprogram based on bytecode, similar
> to existing stuff. It is
Hi all,
Currently for MIPS32 target we do mem writes using
mips32_pracc_write_mem() function. And this works fine, but only
untill kseg0 memory segment is uncached (i.e. K0 field of the Config
Register (CP0 Register 16, Select 0) are set to 0x2, which is a reset
value). However, this memory region
13 matches
Mail list logo
