|
From: | quan |
Subject: | Re: Using parallel port on the Pegasos 2 |
Date: | Sun, 28 Jul 2024 17:43:35 -0500 |
On Sun, 28 Jul 2024, quan wrote:
> I have tried this on qemu 8.2.0 (I downloaded it and compiled with
> --enable-debug), this build does not seem to hit the breakpoint
> portio_write function when writing to 0x3bc while it does on the latest
> qemu git version.
>
> Using the trace:memory_region_ops_write option for 8.2.0, the other
> devices like serial and rtc does get hit, but it never prints a write for
> 'parallel', as if its disabled somehow.
Before implementing relocation of these devices they were at default port
numbers in QEMU v8.2.0 so parallel was at 0x378. Did you try with that
address? You can use 'info mtree' command in QEMU monitor to check which
regions are enabled and where they are.
Regards,
BALATON Zoltan
> Quan
>
> On Sun, Jul 28, 2024 at 2:17 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
>> On Sun, 28 Jul 2024, quan wrote:
>>> I am playing around with the parallel port on the pegasos 2 and I noticed
>>> the following issue:
>>> The parallel port on startup is set to iobase 0x378, then later it gets
>>> remapped to iobase 0x3bc.
>>> When I tried writing to the 0x3bc location with
>>> trace:memory_region_ops_write on, I get logs about writing to the
>> location
>>> 'parallel', so far so good, but the writes don't make it through (it
>> never
>>> calls parallel_ioport_write* functions)
>>>
>>> I traced it through where it calls portio_write, and inside the
>>> portio_write code:
>>> This line always fails for me:
>>> const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
>>> This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the
>> list,
>>> and the 'addr' in the code ranges from (0-15) (address relative to
>> 0x3bc),
>>> so it can never match the parallel io function to execute.
>>>
>>> This seems like a bug to me. I think there is some issue where the
>>> portio_list is not getting updated properly after the remapping to 0x3bc.
>>>
>>> The other devices (Serial, RTC, PM, VGA) responds properly for me, so it
>> is
>>> only the parallel port that has this issue.
>>
>> Is this something that broke recently or can the same be reproduced with
>> QEMU v8.2.0. The relocation of these devices was implemented around commit
>> 35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as well.
>>
>> Regards,
>> BALATON Zoltan
>>
>
[Prev in Thread] | Current Thread | [Next in Thread] |