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=-0.7 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 D042FC2B9F4 for ; Fri, 25 Jun 2021 04:37:25 +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 8D89A61400 for ; Fri, 25 Jun 2021 04:37:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D89A61400 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=fastmail.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwdam-0003lV-Jp for qemu-devel@archiver.kernel.org; Fri, 25 Jun 2021 00:37:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lwda8-00036L-0a for qemu-devel@nongnu.org; Fri, 25 Jun 2021 00:36:44 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:35642) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwda6-0002MT-DY for qemu-devel@nongnu.org; Fri, 25 Jun 2021 00:36:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 451EA2ABAA; Fri, 25 Jun 2021 00:36:35 -0400 (EDT) Date: Fri, 25 Jun 2021 14:36:37 +1000 (AEST) From: Finn Thain To: Mark Cave-Ayland Subject: Re: [PATCH 0/5] dp8393x: fixes for MacOS toolbox ROM In-Reply-To: <246849c9-c674-7b33-6fe0-ddfff1d128fe@ilande.co.uk> Message-ID: <87cdbdeb-1228-f08f-ed15-107f5cf6484@nippy.intranet> References: <20210613163738.2141-1-mark.cave-ayland@ilande.co.uk> <20a706c7-9b44-13cc-b294-1ee0f3cff6bb@amsat.org> <2a2fff87-6e6f-3362-24e3-760f1aea4573@ilande.co.uk> <17f0917-de30-6771-26d0-7a10214221ca@nippy.intranet> <38512250-86bb-7cbd-caca-9bc0378e54e8@ilande.co.uk> <2a99f70-4584-be2f-4d82-72641d65d7a@nippy.intranet> <246849c9-c674-7b33-6fe0-ddfff1d128fe@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Received-SPF: neutral client-ip=98.124.60.144; envelope-from=fthain@fastmail.com.au; helo=kvm5.telegraphics.com.au X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779 autolearn=no 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: aleksandar.rikalo@syrmia.com, jasowang@redhat.com, qemu-devel@nongnu.org, =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , hpoussin@reactos.org, aurelien@aurel32.net, Laurent Vivier Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 24 Jun 2021, Mark Cave-Ayland wrote: > Thanks for the link and the detailed testing information. I've been > trying to understand why you had to set the MAC address in the ARC > firmware so I had a bit of an experiment here. > > The reason that you need to do this is because of the NVRAM > configuration in your command line, in particular -global > ds1225y.size=8200. What this does is extend the NVRAM over the top of > the dp8393x-prom area where QEMU places the NIC MAC address and checksum > on startup, so the NVRAM captures the MAC address reads/writes instead. > The net effect of this is that the empty NVRAM initially reads all zeros > and why an initial setup is required to set the MAC address. > > This can be seen quite clearly in the "info mtree" output: > > 0000000080009000-000000008000b007 (prio 0, i/o): nvram > 000000008000b000-000000008000bfff (prio 0, rom): dp8393x-prom > > However if you completely drop -global ds1225y.size=8200 from your > command line then the NVRAM doesn't overrun into the dp8393x-prom area, > and the ARC firmware picks up the MAC address from QEMU correctly: > > 0000000080009000-000000008000afff (prio 0, i/o): nvram > 000000008000b000-000000008000bfff (prio 0, rom): dp8393x-prom > > I've also looked over the entire SONIC datasheet to see if the PROM > format is documented, and according to that there is no non-volatile > storage available on the chip itself. Yes, that's my understanding also. The relevant National Semicondutor Application Notes seem to include a separate PROM. And if you closely examine the Linux macsonic.c driver, you'll see that the PowerBook 5x0 models get a random MAC address because no-one (outside of Apple) knows where the real MAC address is stored. > Testing shows that the checksum algorithm currently used for the dp8393x > device generates the same result as that generated by the ARC firmware, > which is known to be different than that used by the Q800 machine. > > From this I conclude that the PROM is provided by the board and not the > chipset, and therefore each machine should construct its own PROM > accordingly. I'll send a v2 patchset shortly with these changes which > shall also include the proposed endian patch. > If you potentially have both a ds1225y NVRAM and a dp8393x PROM (for the magnum machine) how do you avoid ending up with conflicting state? Would the two storage devices have to be mutually exclusive?