Re: [Qemu-discuss] Coldfire 5282 Support

[William Mahoney]

Thanks Peter - thoughts below.

> On Oct 25, 2017, at 9:51 AM, Peter Maydell <address@hidden> wrote:
> 
> On 25 October 2017 at 15:36, William Mahoney <address@hidden> wrote:
>> 
>>> 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?
> 
> It depends what exactly is going on, but in general each
> conceptually separate device or lump of functionality
> should be its own QEMU device, assuming the registers are
> together rather than interleaved with each other. You may
> end up with a 'misc' device for general system control.

That makes sense. What I will do then is to continue along this path (one huge 
device) until I know for sure all of them that the board wants to use, then go 
back and make them separate regions. This seems “cleaner” in the long run 
anyway, because of the devices that are already done. Ultimately my aim 
initially is to get it far enough that I can bring up the web server, so things 
like GPIO may be dummied up.

> 
>> 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, ...
> 
> There's not particularly any documentation here. SYS_BUS_DEVICE
> is our general abstraction for 'this is a device object with
> one or more of: memory mapped registers, outbound "irq" lines,
> outbound "gpio" lines, inbound "gpio" lines'. Pretty much
> all devices in an embedded system are SYS_BUS_DEVICE, including
> the interrupt controller. An interrupt controller is just
> a device with inbound gpio lines (corresponding to the interrupt
> lines from the various devices) and usually an outbound irq
> line (to tell the CPU about things). The board code is then
> responsible for wiring interrupt/gpio lines up from one thing
> to another. (Sysbus "irq" lines and gpio lines are really
> exactly the same thing under the hood, it's just convention
> to use the sysbus irq APIs for device IRQ lines.)

Got it (I think). Is there a place to check the size of the IRQ table? The 5282 
has two controllers and I confess I have not read that chapter in the PDF but I 
bet that is a ton of potential requests.

> 
> thanks
> -- PMM