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 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,
>>>>>
>
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 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
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: [Qemu-devel] [PATCH V2] LEON3: Add emulation of AMBA plugplay
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 j...@gaisler.se
AMBA plugplay 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 chout...@adacore.com
---
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 PlugPlay 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) {
+case 0:
+return 0x01003000; /* LEON3 */
+case 0x800:
+return 0x0400f000; /* Memory controller */
+case 0x810:
+return 0x0003e002;
+case 0x814:
+return 0x2000e002;
+case 0x818:
+return 0x4003c002;
+case 0x820:
+return 0x01006000; /* APB bridge @ 0x8000 */
+case 0x830:
+return 0x8000fff2;
+
+default:
+return 0;
+}
+}
+
+static const MemoryRegionOps grlib_ahbpnp_ops = {
+.read = grlib_ahbpnp_read,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void
Re: [Qemu-devel] [PATCH][SPARC] LEON3: Add emulation of AMBA plugplay
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 j...@gaisler.se
AMBA plugplay 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 plugplay 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 chout...@adacore.com
---
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 PlugPlay 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;
+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 void grlib_apbpnp_write(void *opaque, hwaddr addr,
+uint64_t value, unsigned size)
+{
+}
+
+static const MemoryRegionOps grlib_apbpnp_ops = {
+.write = grlib_apbpnp_write,
+.read = grlib_apbpnp_read,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static int grlib_apbpnp_init(SysBusDevice *dev)
+{
+APBPNP *pnp = GRLIB_APB_PNP(dev);
+
+memory_region_init_io(pnp-iomem, OBJECT(pnp), grlib_apbpnp_ops, pnp,
+ apbpnp, APBPNP_REG_SIZE);
+
+sysbus_init_mmio(dev, pnp-iomem
