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 <peter.mayd...@linaro.org> wrote:
>
> On 15 September 2017 at 21:41, William Mahoney <wmaho...@unomaha.edu> 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
