[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] Coldfire 5282 Support
From: |
William Mahoney |
Subject: |
Re: [Qemu-discuss] Coldfire 5282 Support |
Date: |
Wed, 25 Oct 2017 14:36:06 +0000 |
> On Oct 25, 2017, at 1:37 AM, Peter Maydell <address@hidden> wrote:
>
> On 24 October 2017 at 21:34, William Mahoney <address@hidden> wrote:
>> Quick question. On the MCF5282 there is a huge memory mapped IO starting at
>> 0x40000000 and going for 1A0000. All of the IO is relative to this starting
>> point, so when my call back for an I/O write happens, for example, I get the
>> offset into the area. Fine.
>
> What's actually in this region that wants the offset from the
> base of it? Often "all the IO is in this window" designs are
> really just "there are lots of different IO devices which
> are at different places within this range". That is, is
> there actually any behaviour needed for "in the IO range
> but not actually a device” ?
It is a “there are lots of different I/O”… design. It includes all the UARTs,
FEC, timers, interrupt controllers (2 - more on that in a sec), … So what I
have been doing is to start the guest and see which end up unsupported, add
them to a switch, try again, … to see which are actually necessary for the
board and which are not. I <could> do a separate region for each one but
there’s probably 30 registers so far spread over six or seven device types. It
just seemed simpler to consolidate. But! Since the UARTs, timers, and ethernet
are already done, but in this range, maybe this is not the best approach?
I don’t have a problem going down this path and then, once I know what is
needed, doing a region for each device.
>
>> 1) If I define the large region and THEN define the small one (since FEC
>> support is already done), will the “more recent” region get the I/O requests
>> and I’m good to go? And if so, will my “below the FEC” part and the “above
>> the FEC” part still have the correct offsets?
>
> You can do this sort of thing, but you need to define
> the region priorities (using memory_region_add_subregion_overlap()
> for at least one of them. See docs/devel/memory.txt and
> in particular the section on overlapping regions.
Ah! Good pointer, I will take a look.
Related question. Where can I go look to get a better understanding of how the
interrupts work? The supported 5208 has one PIC but the 5282 has two. In the
5208 code it uses sys bus_connect_irq() which references irqs[i]. (Spell
correcting made that array called “irks”!) Just general questions like is the
array big enough, what’s SYS_BUS_DEVICE do, ...
>
> thanks
> -- PMM
- Re: [Qemu-discuss] Coldfire 5282 Support, Thomas Huth, 2017/10/03
- Re: [Qemu-discuss] Coldfire 5282 Support, William Mahoney, 2017/10/03
- Re: [Qemu-discuss] Coldfire 5282 Support, Thomas Huth, 2017/10/03
- Re: [Qemu-discuss] Coldfire 5282 Support, William Mahoney, 2017/10/03
- Re: [Qemu-discuss] Coldfire 5282 Support, Thomas Huth, 2017/10/03
- Re: [Qemu-discuss] Coldfire 5282 Support, Peter Maydell, 2017/10/03
- Re: [Qemu-discuss] Coldfire 5282 Support, William Mahoney, 2017/10/03
- Re: [Qemu-discuss] Coldfire 5282 Support, William Mahoney, 2017/10/05
- Re: [Qemu-discuss] Coldfire 5282 Support, William Mahoney, 2017/10/24
- Re: [Qemu-discuss] Coldfire 5282 Support, Peter Maydell, 2017/10/25
- Re: [Qemu-discuss] Coldfire 5282 Support,
William Mahoney <=
- Re: [Qemu-discuss] Coldfire 5282 Support, Peter Maydell, 2017/10/25
- Re: [Qemu-discuss] Coldfire 5282 Support, William Mahoney, 2017/10/25
- Re: [Qemu-discuss] Coldfire 5282 Support, William Mahoney, 2017/10/31