On Wed, Oct 2, 2013 at 2:15 PM, Stefan Kristiansson
<stefan.kristians...@saunalahti.fi> wrote:
> On Wed, Oct 2, 2013 at 8:33 AM, Jia Liu <pro...@gmail.com> wrote:
>>
>> Hi Sebastian,
>>
>> On Wed, Oct 2, 2013 at 1:12 PM, Sebastian Macke <sebast...@macke.de>
>> wrote:
>> > Hi,
>> >
>> > this patch corrects two problems for the OpenRISC Target in QEMU. The
>> > first
>> > one corrects one obvious bug
>> > concerning the handling of page faults while reading from a page.
>>
>> @@ -102,7 +102,7 @@ int cpu_openrisc_get_phys_data(OpenRISCCPU *cpu,
>> }
>> }
>>
>> - if ((rw & 0) && ((right & PAGE_READ) == 0)) {
>> + if (!(rw & 1) && ((right & PAGE_READ) == 0)) {
>> return TLBRET_BADADDR;
>> }
>> if ((rw & 1) && ((right & PAGE_WRITE) == 0)) {
>>
>> They are just two type of one code...
>
>
> No, (rw & 0) always evaluates to 0.
>
>>
>>
>> > The second
>> > part removes a non-conforming behavior for the first page of the memory.
>>
>> @@ -122,13 +122,6 @@ static int cpu_openrisc_get_phys_addr(OpenRISCCPU
>> *cpu,
>> {
>> int ret = TLBRET_MATCH;
>>
>> - /* [0x0000--0x2000]: unmapped */
>> - if (address < 0x2000 && (cpu->env.sr & SR_SM)) {
>> - *physical = address;
>> - *prot = PAGE_READ | PAGE_WRITE;
>> - return ret;
>> - }
>> -
>>
>> May you please explain more about why the first page is non-conforming?
>> The Arch manual told me 0x0000--0x2000 is unmapped.
>
>
> It shows an example where *software* leaves 0x0000 - 0x2000 unmapped,
> the hardware should still allow for this area to be mapped.
OK, thank you. I will send a PULL Request soon.
Reviewed-by: Jia Liu <pro...@gmail.com>
>
> Stefan
Regards,
Jia
