Hello QEMU users.
I am interested in looking into a port for the Motorola Coldfire 5282. I saw
that others in the Coldfire family were supported, like the 5208 eval board and
the 5206 as a bare CPU. When I started looking into it I saw that several files
(e.g. coldfire/flexcan.h and coldfire/in
On 01.09.2017 21:03, William Mahoney wrote:
> Hello QEMU users.
>
> I am interested in looking into a port for the Motorola Coldfire 5282. I saw
> that others in the Coldfire family were supported, like the 5208 eval board
> and the 5206 as a bare CPU. When I started looking into it I saw that s
> On Sep 4, 2017, at 3:11 AM, Thomas Huth wrote:
>
> On 01.09.2017 21:03, William Mahoney wrote:
>> Hello QEMU users.
>>
>> I am interested in looking into a port for the Motorola Coldfire 5282. I saw
>> that others in the Coldfire family were supported, like the 5208 eval board
>> and the 52
On 5 September 2017 at 20:30, William Mahoney wrote:
> Thanks Thomas. One more question. Somewhere there must be a "what
> parts to look for where” document. You know, a “If you are interested
> in the device support for CPU XYZ, you look in the …XYZ directory” etc.
There's no document particular
> On Sep 5, 2017, at 4:37 PM, Peter Maydell wrote:
>
> On 5 September 2017 at 20:30, William Mahoney wrote:
>> Thanks Thomas. One more question. Somewhere there must be a "what
>> parts to look for where” document. You know, a “If you are interested
>> in the device support for CPU XYZ, you loo
On 06.09.2017 00:04, William Mahoney wrote:
>
>> On Sep 5, 2017, at 4:37 PM, Peter Maydell wrote:
>>
>> On 5 September 2017 at 20:30, William Mahoney wrote:
[...]
>>> I’d like to find this and/or anything else to clue me in before
>>> starting as to the level of difficulty to add 5282. I mean, I
I thought I would look at the -bios first and I had some time this afternoon.
If you’re the right age group you will understand when I say "YOU ARE IN A MAZE
OF TWISTY LITTLE PASSAGES, ALL ALIKE”.
"digic_load_rom()" knows the filename via an extern “bios_name” which is at
“include/sysemu/sysem
On 08.09.2017 22:32, William Mahoney wrote:
>
> I thought I would look at the -bios first and I had some time this afternoon.
> If you’re the right age group you will understand when I say "YOU ARE IN A
> MAZE OF TWISTY LITTLE PASSAGES, ALL ALIKE”.
No, looks like I'm too young - my first comput
On 8 September 2017 at 21:32, William Mahoney wrote:
> "digic_load_rom()" knows the filename via an extern “bios_name” which is at
> “include/sysemu/sysemu.h” but really lives in “vl.c”. It is set based on
> “machine_ops” that comes from “qemu_get_machine_opts()” which in turn comes
> from “emu
OK a bit of an update and another question or two. First, you’re right, “it
just plain works”. What I’d like to verify today is that I am “doing the right
thing” is all.
1) I made a copy of qemu/hw/m68k/mcf5208.c as mcf5282.c and I - for now -
changed all 5208 to 5282 inside the source. Threw
On 12.09.2017 21:05, William Mahoney wrote:
> OK a bit of an update and another question or two. First, you’re right, “it
> just plain works”. What I’d like to verify today is that I am “doing the
> right thing” is all.
>
> 1) I made a copy of qemu/hw/m68k/mcf5208.c as mcf5282.c and I - for now
> On Sep 13, 2017, at 3:34 AM, Thomas Huth wrote:
>
> On 12.09.2017 21:05, William Mahoney wrote:
>> OK a bit of an update and another question or two. First, you’re right, “it
>> just plain works”. What I’d like to verify today is that I am “doing the
>> right thing” is all.
>>
>> 1) I made
On 13.09.2017 16:31, William Mahoney wrote:
[...]
> By the way, there is a link to a uClinux image on the emu documentation pages
> but the link times out. Is there a uClinux 5208 kernel image somewhere else?
> I only wanted to try that to make sure that everything else (serial ports) is
> set u
Le 13/09/2017 à 19:48, Thomas Huth a écrit :
> On 13.09.2017 16:31, William Mahoney wrote:
> [...]
>> By the way, there is a link to a uClinux image on the emu documentation
>> pages but the link times out. Is there a uClinux 5208 kernel image somewhere
>> else? I only wanted to try that to make
Hi Laurent;
I grabbed it and it boots up just fine. Thanks!
Spent a few hours this afternoon looking at your 5208 code Thomas. Some
thoughts in no particular order.
1) 5208 has two timers, I walked through the code, looks good. 5282 has four…
Easily changeable.
2) The only thing other than th
On 15 September 2017 at 21:41, William Mahoney wrote:
> 3) Can of worms. The 5282 allows you to move the base address
> of the control registers, the start address of the SRAM, all
> sorts of things. The control registers are all offset from a
> default address when the chip is reset but in theor
Thanks Peter!
Couple of new things now that I had an afternoon to look again. I have
discovered that the eval board I can get my hands on is a 5272 and not a 5282,
and although the eval board for a 5208 comes with a kernel the 5282 does not.
It only has the ROM debugger. Which makes me want to
On 26.09.2017 23:12, William Mahoney wrote:
> Thanks Peter!
>
> Couple of new things now that I had an afternoon to look again. I have
> discovered that the eval board I can get my hands on is a 5272 and not a
> 5282, and although the eval board for a 5208 comes with a kernel the 5282
> does no
Hi Thomas;
I was telling this to Peter as well offline. The initial problem just FYI was
that the routing on the m68k side was nonexistent, so it wasn’t even sending
anything to the net drivers at all. I turned on the debugging in the net driver
and there was no traffic. It looks like there is
On 03.10.2017 15:21, William Mahoney wrote:
> Hi Thomas;
>
> I was telling this to Peter as well offline. The initial problem just FYI was
> that the routing on the m68k side was nonexistent, so it wasn’t even sending
> anything to the net drivers at all. I turned on the debugging in the net
>
I also get everything from DHCP and I am correctly set as the .15 address, etc.
eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:
On 03.10.2017 15:48, William Mahoney wrote:
> I also get everything from DHCP and I am correctly set as the .15 address,
> etc.
>
> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
> inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MUL
On 3 October 2017 at 18:14, Thomas Huth wrote:
> Not sure, but it might be normal that the host is not answering here.
> The "user" networking is using NAT, so the host OS might think that it
> is talking to itself here and thus ARP is not needed. You might want to
> try "tap" networking instead.
OK so really even though I see the driver sending the ARP requests, they’re not
actually ever making it to the host, even though the PCAP file shows them. In
other words, the PCAP file is "on the guest side" of the connection not "the
host side of the connection". Correct?
If that’s the case I
OK I took a look at slirp.c as you suggested.
I put in some fprintf’s in slip.c for the ARP requests and also in
arp_table_add and arp_table_search in arp_table.c. In the process I learned a
lot about how the ARP services work within QEMU and in the process also
realized what I was doing wrong.
Quick question. On the MCF5282 there is a huge memory mapped IO starting at
0x4000 and going for 1A. 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.
In this area is the Fast Ethernet Con
On 24 October 2017 at 21:34, William Mahoney wrote:
> Quick question. On the MCF5282 there is a huge memory mapped IO starting at
> 0x4000 and going for 1A. 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
> On Oct 25, 2017, at 1:37 AM, Peter Maydell wrote:
>
> On 24 October 2017 at 21:34, William Mahoney wrote:
>> Quick question. On the MCF5282 there is a huge memory mapped IO starting at
>> 0x4000 and going for 1A. All of the IO is relative to this starting
>> point, so when my call b
On 25 October 2017 at 15:36, William Mahoney wrote:
>
>> On Oct 25, 2017, at 1:37 AM, Peter Maydell wrote:
>>
>> On 24 October 2017 at 21:34, William Mahoney wrote:
>>> Quick question. On the MCF5282 there is a huge memory mapped IO starting at
>>> 0x4000 and going for 1A. All of the IO
Thanks Peter - thoughts below.
> On Oct 25, 2017, at 9:51 AM, Peter Maydell wrote:
>
> On 25 October 2017 at 15:36, William Mahoney wrote:
>>
>>> On Oct 25, 2017, at 1:37 AM, Peter Maydell wrote:
>>>
>>> On 24 October 2017 at 21:34, William Mahoney wrote:
Quick question. On the MCF5282
>>
>>> 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
On 31 October 2017 at 22:10, William Mahoney wrote:
> But of course the code writes to the interrupt controller
> mask registers to enable and disable things. How does this
> get “wired in” to qemu? I will need to tell it “yes you can
> generate interrupt 27 now”?
>
> Just aim me at a good example
32 matches
Mail list logo
