From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9149EC433E0 for ; Tue, 16 Mar 2021 22:21:09 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E78E864EF9 for ; Tue, 16 Mar 2021 22:21:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E78E864EF9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=eik.bme.hu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:51078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMI3o-0005X5-1P for qemu-devel@archiver.kernel.org; Tue, 16 Mar 2021 18:21:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMHYu-0008Gq-TE; Tue, 16 Mar 2021 17:49:12 -0400 Received: from zero.eik.bme.hu ([152.66.115.2]:39957) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMHYp-0001Pb-U4; Tue, 16 Mar 2021 17:49:12 -0400 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id C5092746353; Tue, 16 Mar 2021 22:49:03 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id A16D17462DB; Tue, 16 Mar 2021 22:49:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id A00C57456B4; Tue, 16 Mar 2021 22:49:03 +0100 (CET) Date: Tue, 16 Mar 2021 22:49:03 +0100 (CET) From: BALATON Zoltan To: Mark Cave-Ayland Subject: Re: [PATCH v7 0/8] Pegasos2 emulation In-Reply-To: <55cbbb40-6b83-3037-0e24-f3c78a0e463b@ilande.co.uk> Message-ID: <64c77f89-a890-2513-a8db-ebdc153f3dd7@eik.bme.hu> References: <85548594-aaa1-8d3a-cedf-d2dd92f05028@eik.bme.hu> <276e8961-d058-c47e-82dd-1715881607d5@amsat.org> <4ce33c11-af3c-4a18-fccb-9c9bdb2b26c2@vivier.eu> <79ac3f4d-8ba4-1326-976f-8e2fa52230c8@eik.bme.hu> <55cbbb40-6b83-3037-0e24-f3c78a0e463b@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: pass client-ip=152.66.115.2; envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= , qemu-devel@nongnu.org, Laurent Vivier , qemu-ppc@nongnu.org, Paolo Bonzini , David Gibson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: > On 16/03/2021 17:25, BALATON Zoltan wrote: >> On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: >>> On 16/03/2021 13:06, BALATON Zoltan wrote: >>>>> The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 >>>>> machine, does it? >>>> >>>> It is needed (as well as all other patches in the series). Patch 1 is >>>> needed for getting serial output which is the only way to communicate >>>> with the Pegasos2 firmware so it's really hard to boot anything without >>>> it. >>> >>> Just having a quick look at patch 1: presumably the issue here is that the >>> Pegasos 2 firmware moves the serial ports to a different address on >>> startup. If you know what that address is, then why not simply change the >>> serial port base address(es) on the SuperIO device from the default? >> >> I had that as first version but other guests may expect the serial at the >> default address or set it up differently and we can emulate the device more >> fully this way that works with all guests which is also more like the >> device works. So putting it at a default address would be a step back. I >> can attempt that if this approach cannot be used but so far nobody said so. > > That would certainly be my first choice, as swapping out the memory regions > within the ISA bus without its knowledge is likely to cause problems (I can > see ioport_id being incorrect for one). Did you check what's that used for? Unlikely to cause any problems other than displaying initial value of port address instead of current address in device ID but that could be argued about if an ID should change or stay the same as initially. Easily fixable either way. > Do the guest OSs actually use this feature at all? I don't think I've ever > seen such registers being used within QEMU, OSs tend to simply relocate the > IO space base address using the BAR if required. The ISA devices don't have io BAR, they are relocatable _within_ ISA IO space by the config registers of the VIA superio chip. But the two guests that currently boot (MorphOS and Linux) don't seems to change default set by the firmware so we can go with the firmware defaults which is less correct than actually emulating what the chip does but whatever. (AmigaOS may also boot but has no gfx driver so can't really check at the moment.) > If Linux/MorphOS work with a fixed address then that's good enough for now: > the code should look something like this: > > dev = qdev_new(TYPE_SUPER_IO); > serial_dev = object_resolve_path_component(OBJECT(dev), "serial0")); > qdev_prop_set_uint32(dev, "iobase", 0x1234); > qdev_realise_and_unref(dev, &error_fatal); I've sent a v8 dropping patch 1 and setting a default but using the callback ISA superio has for this for that which is a bit cleaner IMO. Could this turned into a pull request by somebody now? Regards, BALATON Zoltan