qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LEON3 networking


From: Jiri Gaisler
Subject: Re: LEON3 networking
Date: Thu, 24 Oct 2019 09:31:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 10/24/19 12:31 AM, Philippe Mathieu-Daudé wrote:
> Hi Jiri,
>
> On 10/23/19 9:55 PM, Jiri Gaisler wrote:
>> BTW, here is a patch that you might want to apply to qemu if you intend
>> to run RTEMS on leon3. The plug&play area must support byte accesses,
>> which is used by the RTEMS grlib scanning functions...
>
> Do you mean this one?
>
> http://gaisler.org/qemu/qemu-4.1.0-leon3.patch


Yes.

>
> -- >8 --
> --- a/hw/misc/grlib_ahb_apb_pnp.c
> +++ b/hw/misc/grlib_ahb_apb_pnp.c
> @@ -228,6 +228,9 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr 
> offset, unsigned size)
>  {
>      APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);
>
> +    if (size != 4)
> +        return apb_pnp->regs[offset >> 2] >> ((~offset & 3) * 8);
> +
>      return apb_pnp->regs[offset >> 2];
>  }
>
> ---
>
> But then this is incorrect for 16-bit accesses.

Correct, it only fixes 8-bit accesses so that RTEMS can boot.


>
> The proper patch might be:
>
> -- >8 --
> @@ -234,6 +234,13 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr 
> offset, unsigned size)
>  static const MemoryRegionOps grlib_apb_pnp_ops = {
>      .read       = grlib_apb_pnp_read,
>      .endianness = DEVICE_BIG_ENDIAN,
> +    .valid = {
> +        .min_access_size = 1,
> +    },
> +    .impl = {
> +        .min_access_size = 4,
> +        .max_access_size = 4,
> +    },
>  };
>

I don't know enough about qemu internals to have an opinion on this, but it 
certainly looks much more elegant than my simple fix .. :-)

Jiri.

> ---
>
> (Unrelated note, this device model lacks the MemoryRegionOps::write handler).
>
>> Jiri.
>>
>> On 10/23/19 8:37 PM, Jiri Gaisler wrote:
>>> Leon3 uses the GRETH ethernet IP core for networking. You would need to
>>> write a qemu emulation model of it to get networking support. The GRETH
>>> is fairly well described in the GRLIB IP manual, so it should not be
>>> impossible. The core is also available in open-source (VHDL) if you need
>>> to look up some finer details ... :-)
>>>
>>> Jiri.
>>>
>>> On 10/23/19 6:59 PM, Joshua Shaffer wrote:
>>>> Does anyone know what needs implemented to get networking supported?
>>>>
>>>> Joshua
>>>>
>>>> On Wed, Oct 16, 2019 at 6:34 AM Fabien Chouteau <address@hidden> wrote:
>>>>> Hello people,
>>>>>
>>>>> On 15/10/2019 18:57, Philippe Mathieu-Daudé wrote:
>>>>>> Hi Joshua,
>>>>>>
>>>>>> On 10/15/19 3:17 PM, Joshua Shaffer wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've been using the LEON3 port of qemu, and am wondering if anyone has 
>>>>>>> touched the networking setup for such since the thread here: 
>>>>>>> https://lists.rtems.org/pipermail/users/2014-September/028224.html
>>>>>> Thanks for sharing this!
>>>>>>
>>>>>> Good news, Jiri keeps rebasing his patch with the latest stable version.
>>>>>> Bad news, he didn't not signed his work with a "Signed-off-by" tag so we 
>>>>>> can not take this as it into the mainstream repository, see 
>>>>>> https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
>>>>>>
>>>>> The Gaisler patches have been rewrote by my colleague Frederic (in CC) 
>>>>> and they are now in mainstream.
>>>>> (see https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg03869.html)
>>>>>
>>>>> But none of them are implementing network support, and I never heard of 
>>>>> someone working on network for leon3.
>>>>>
>>>>> Regards,
>>>>>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]