Re: [Qemu-discuss] Coldfire 5282 Support

[William Mahoney]

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 jump directly to what I 
really want to do anyway, which is to run the FLASH out of an Allen Bradley PLC 
that has a 5282 in it. Ultimately I want to monitor what the code in the PLC 
does when you hit it with (for example) HTTP requests. So...

1) First, on the ColdFire 5208 with time uClinux kernel I can’t seem to get the 
networking to go. I figured I should make sure that works on the 5208 before I 
try to get it to work on the PLC code. I’m trying to use “user” networking but 
no combination of -net user,id= … seems to work at all even with restrict=off. 
Can someone aim me at a known-to-work process for this? I sure can’t get any 
netcat between the guest and a netcat running on Linux. I don’t need traffic to 
leave the VM at all, just be able to let me get to ports in the guest from an 
additional xterm or local browser.

2) I rebuilt all of qemu with tracing on, and followed the bouncing ball on 
numerous websites on setting up the events file (e.g. /tmp/events). 
./simpletrace.py seems to want to say:

Traceback (most recent call last):
  File "./qemu/scripts/simpletrace.py", line 262, in <module>
    run(Formatter())
  File "./qemu/scripts/simpletrace.py", line 236, in run
    events = read_events(open(sys.argv[1], 'r'))
  File 
"/mnt/hgfs/billmahoney/Dropbox/Projects/PLC_on_QEMU/qemu/scripts/tracetool/__init__.py",
 line 309, in read_events
    event = Event.build(line)
  File 
"/mnt/hgfs/billmahoney/Dropbox/Projects/PLC_on_QEMU/qemu/scripts/tracetool/__init__.py",
 line 224, in build
    assert m is not None
AssertionError

I could start reading the python but I followed the documentation… Hm...




> On Sep 15, 2017, at 4:39 PM, Peter Maydell <address@hidden> wrote:
> 
> On 15 September 2017 at 21:41, William Mahoney <address@hidden> 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 theory the code
>> can come along and say “well from now on the base address for
>> the control registers is so-and-so”. In the startup code,
>> there’s those calls such as “memory_region_allocate_system_memory”
>> and “…add_subregion” and so on. What happens if after a system
>> starts and is being emulated, we need to move the regions or
>> subregions?
> 
> You can rearrange things at runtime if you need to. You basically
> need to keep hold of a pointer to the MemoryRegion (typically
> by having them owned by some device or other which is also
> the thing with the control registers), and then you can
> enable/disable/map/unmap etc as required. Depending on
> exactly what the level of control provided is, this task
> may be made easier by adding in suitable "container" memory
> regions, so you can just move or the entire container
> (which automatically moves all the regions inside it)
> rather than moving multiple individual regions.
> 
>> So also, philosophically you might say, does a qemu for a new
>> target emulate everything that the chip can do, or only what’s
>> needed for, say, Linux?
> 
> Our general principle is that it should start with enough
> to do something useful, but it doesn't have to have
> complete functionality. You may find create_unimplemented_device()
> useful as a way to stub out things you don't provide --
> it allows the user to turn on logging of when the guest
> accesses them.
> 
> thanks
> -- PMM