Re: [Qemu-devel] [V6, 2/7] nios2: Add architecture emulation support

[Marek Vasut]

On 11/13/2016 05:09 PM, Guenter Roeck wrote:
> Hi Marek,
> 
> On 11/13/2016 04:01 AM, Marek Vasut wrote:
>>>
>>> diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
>>> index 564dbae..e0a9aff 100644
>>> --- a/hw/nios2/boot.c
>>> +++ b/hw/nios2/boot.c
>>> @@ -73,6 +73,11 @@ static void main_cpu_reset(void *opaque)
>>>      }
>>>  }
>>>
>>> +static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
>>> +{
>>> +    return addr - 0xc0000000LL;
>>> +}
>>> +
>>>  static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t
>>> ramsize,
>>>                            const char *kernel_cmdline, const char
>>> *dtb_filename)
>>>  {
>>> @@ -97,21 +102,16 @@ static int nios2_load_dtb(struct nios2_boot_info
>>> bi, const uint32_t ramsize,
>>>
>>>      if (bi.initrd_start) {
>>>          qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start",
>>> -                              bi.initrd_start);
>>> +                              translate_kernel_address(NULL,
>>> bi.initrd_start));
>>>
>>>          qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
>>> -                              bi.initrd_end);
>>> +                              translate_kernel_address(NULL,
>>> bi.initrd_end));
>>>      }
>>>
>>>      cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
>>>      return fdt_size;
>>>  }
>>>
>>> -static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
>>> -{
>>> -    return addr - 0xc0000000LL;
>>> -}
>>> -
>>>  void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
>>>
>>>
>>> This is my command line, running your patch series plus the above fixup
>>> on top of
>>> the qemu master branch:
>>
>> Uhm, how could that patch fix the DT passing for you ? I am still
>> looking into the DT passing, that's quite odd.
>>
> 
> The problem isn't that much that dtb passing fails without the above fix,
> the problem is that memory initialization fails if wrong addresses are
> passed in the initrd properties (probably because the kernel tries to
> access or free memory that does not exist). This results in a kernel hang
> (endless loop) in memory initialization code.

I was looking through that initcode today and through the Nios2 DTS, it
looks like quite an inconsistent mess of User and Kernel addresses used
there.

-- 
Best regards,
Marek Vasut