Re: LEON3 networking
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 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, >>
Re: LEON3 networking
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...
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 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,
>>>
diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index 7338461694..eaaedbfbcc 100644
--- 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];
}
Re: LEON3 networking
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
>>>> 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,
>>>>>
>
qemu-devel@nongnu.org
On 10/08/2014 05:38 PM, Andreas Färber wrote:
> Hi,
>
> Am 08.10.2014 um 16:19 schrieb Fabien Chouteau:
>> From: Jiri Gaisler
>>
>> AMBA plug&play is used by kernels to probe available devices (Timers,
>> UART, etc...). This is a static declaration of devices implemented in
>> QEMU. In the future, a more advanced version could compute those
>> information directly from the device tree.
>
> Interesting. There's quite some magic numbers in the read functions; I
> wonder if you could read them via QOM if you actually give the devices a
> canonical path or search by type? You may want to peek at ACPI code.
The plug&play area is similar in function to the PCI configuration
space, indicating vendor/device ID's, address range, interrupt number
etc. of on-chip IP cores. The 'magic' numbers could be generated by
generic functions taking these parameters as inputs. This would
certainly make the code more readable, and easily extended in the
future. Would such a solution be acceptable?
>
>>
>> Signed-off-by: Fabien Chouteau
>> ---
>> hw/sparc/Makefile.objs |1 +
>> hw/sparc/grlib_ambapnp.c | 206
>> ++
>> hw/sparc/leon3.c |6 ++
>> include/hw/sparc/grlib.h | 36
>> 4 files changed, 249 insertions(+)
>> create mode 100644 hw/sparc/grlib_ambapnp.c
>>
>> diff --git a/hw/sparc/Makefile.objs b/hw/sparc/Makefile.objs
>> index c987b5b..e763701 100644
>> --- a/hw/sparc/Makefile.objs
>> +++ b/hw/sparc/Makefile.objs
>> @@ -1 +1,2 @@
>> obj-y += sun4m.o leon3.o
>> +obj-$(CONFIG_GRLIB) += grlib_ambapnp.o
>> diff --git a/hw/sparc/grlib_ambapnp.c b/hw/sparc/grlib_ambapnp.c
>> new file mode 100644
>> index 000..dfadd5c
>> --- /dev/null
>> +++ b/hw/sparc/grlib_ambapnp.c
>> @@ -0,0 +1,206 @@
>> +/*
>> + * QEMU GRLIB AMBA Plug&Play Emulator
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> copy
>> + * of this software and associated documentation files (the "Software"), to
>> deal
>> + * in the Software without restriction, including without limitation the
>> rights
>> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>> + * copies of the Software, and to permit persons to whom the Software is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> FROM,
>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>> + * THE SOFTWARE.
>> + */
>> +
>> +#include "hw/sysbus.h"
>> +
>> +#define APBPNP_REG_SIZE 4096 /* Size of memory mapped registers */
>> +
>> +#define TYPE_GRLIB_APB_PNP "grlib,apbpnp"
>
> If you move the two TYPE_* constants to grlib.h, you can reuse them.
>
>> +#define GRLIB_APB_PNP(obj) \
>> +OBJECT_CHECK(APBPNP, (obj), TYPE_GRLIB_APB_PNP)
>> +
>> +typedef struct APBPNP {
>> +SysBusDevice parent_obj;
>> +MemoryRegion iomem;
>> +} APBPNP;
>> +
>> +static uint64_t grlib_apbpnp_read(void *opaque, hwaddr addr,
>> + unsigned size)
>
> Indentation is off by one for all read/write functions.
>
>> +{
>> +uint64_t read_data;
>> +addr &= 0xfff;
>> +
>> +/* Unit registers */
>> +switch (addr & 0xffc) {
>> +case 0x00:
>> +read_data = 0x0400f000; /* Memory controller */
>> +break;
>> +case 0x04:
>> +read_data = 0xfff1;
>> +break;
>> +case 0x08:
>> +read_data = 0x0100c023; /* APBUART */
>> +break;
>> +case 0x0C:
>> +read_data = 0x0010fff1;
>> +break;
>> +case 0x10:
>> +read_data = 0x0100d040; /* IRQMP */
>> +break;
>> +case 0x14:
>> +read_data = 0x0020fff1;
>> +break;
>> +cas
qemu-devel@nongnu.org
I am a bit against the merge of AHB and APB initialization into
the same function. A grlib system can have any number of AHB and APB
buses, so there really should be a separate init routine per bus
as in the original patch.
Jiri.
On 10/09/2014 01:05 PM, Fabien Chouteau wrote:
> From: Jiri Gaisler
>
> AMBA plug&play is used by kernels to probe available devices (Timers,
> UART, etc...). This is a static declaration of devices implemented in
> QEMU. In the future, a more advanced version could compute those
> information directly from the device tree.
>
> Signed-off-by: Fabien Chouteau
> ---
>
> V2:
> - AHB and APB PNP are now grouped in one device
> - Initialisation moved to .instance_init
> - Minor fixes
>
> hw/sparc/Makefile.objs |1 +
> hw/sparc/grlib_ambapnp.c | 149
> ++
> hw/sparc/leon3.c |3 +
> include/hw/sparc/grlib.h | 22 +++
> 4 files changed, 175 insertions(+)
> create mode 100644 hw/sparc/grlib_ambapnp.c
>
> diff --git a/hw/sparc/Makefile.objs b/hw/sparc/Makefile.objs
> index c987b5b..e763701 100644
> --- a/hw/sparc/Makefile.objs
> +++ b/hw/sparc/Makefile.objs
> @@ -1 +1,2 @@
> obj-y += sun4m.o leon3.o
> +obj-$(CONFIG_GRLIB) += grlib_ambapnp.o
> diff --git a/hw/sparc/grlib_ambapnp.c b/hw/sparc/grlib_ambapnp.c
> new file mode 100644
> index 000..dd53004
> --- /dev/null
> +++ b/hw/sparc/grlib_ambapnp.c
> @@ -0,0 +1,149 @@
> +/*
> + * QEMU GRLIB AMBA Plug&Play Emulator
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "hw/sysbus.h"
> +#include "hw/sparc/grlib.h"
> +
> +/* Size of memory mapped registers */
> +#define APBPNP_REG_SIZE (4096 - 8)
> +#define AHBPNP_REG_SIZE 4096
> +
> +#define GRLIB_AMBA_PNP(obj) \
> +OBJECT_CHECK(AMBAPNP, (obj), TYPE_GRLIB_AMBA_PNP)
> +
> +typedef struct AMBAPNP {
> +SysBusDevice parent_obj;
> +MemoryRegion ahb_iomem;
> +MemoryRegion apb_iomem;
> +} AMBAPNP;
> +
> +/* APB PNP */
> +
> +static uint64_t grlib_apbpnp_read(void *opaque, hwaddr addr,
> + unsigned size)
> +{
> +uint64_t read_data;
> +addr &= 0xfff;
> +
> +/* Unit registers */
> +switch (addr & 0xffc) {
> +case 0x00:
> +read_data = 0x0400f000; /* Memory controller */
> +break;
> +case 0x04:
> +read_data = 0xfff1;
> +break;
> +case 0x08:
> +read_data = 0x0100c023; /* APBUART */
> +break;
> +case 0x0C:
> +read_data = 0x0010fff1;
> +break;
> +case 0x10:
> +read_data = 0x0100d040; /* IRQMP */
> +break;
> +case 0x14:
> +read_data = 0x0020fff1;
> +break;
> +case 0x18:
> +read_data = 0x01011006; /* GPTIMER */
> +break;
> +case 0x1C:
> +read_data = 0x0030fff1;
> +break;
> +
> +default:
> +read_data = 0;
> +}
> +if (size == 1) {
> +read_data >>= (24 - (addr & 3) * 8);
> +read_data &= 0x0ff;
> +}
> +return read_data;
> +}
> +
> +static const MemoryRegionOps grlib_apbpnp_ops = {
> +.read = grlib_apbpnp_read,
> +.endianness = DEVICE_NATIVE_ENDIAN,
> +};
> +
> +/* AHB PNP */
> +
> +static uint64_t grlib_ahbpnp_read(void *opaque, hwaddr addr,
> + unsigned size)
> +{
> +addr &= 0xffc;
> +
> +/* Unit registers */
> +switch (addr) {
>
