From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 8A1063857C4E for ; Thu, 28 Oct 2021 12:24:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A1063857C4E Received: by mail-oi1-x229.google.com with SMTP id y128so7981417oie.8 for ; Thu, 28 Oct 2021 05:24:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j2qZdEu06KEBFkmGkgUzf7kRqrWyreB+4Rj8F+/+FZc=; b=6n3BRCrboWcqX5mjLfJxHMFDiHTAMqLMJwScCg8Rr1Ap+SGEa2mzaqIYnCbNFlLfhQ cvQ2Aiad7tKLeqM42TjwHhuIiDzXy3d8Jqh6k3emP9eU2Acu8KXP3AZWVxUtq7RFUgDS SGqsDJ1arNtLzAE2yMEKJdCiScGRAWpYGtLdKfFue2BY8PDMrrjpYcm3gRyEhbPKhWje f/5bVS/joBK/YZTbIVCWiB61hQ5w9XDTO6Zald8TSHMcQSJyT3EIn9lpdl4Ig9jYepWk mnBk/Z1OT2lcGxfW0C8SJ78jPlA/QZFNQv1QxOkTxuD/3dXcUC0FKX8yyTYPi8eof0eG QzxA== X-Gm-Message-State: AOAM530Q3kikPiHxx7Xs3SQcRj1Kxu3Kx2CQ3w4gUjss0AwkmWZNhLTU qrKYynE9NXYnKbBtFok6qr6Yww== X-Google-Smtp-Source: ABdhPJwMggFDGpx1pVkZxp5DaiKCTTzCw2cP2AxIXWxCGF4qerGLlCHDnFFdyZ95S1Df8DaCq9QvzA== X-Received: by 2002:aca:be54:: with SMTP id o81mr8273430oif.64.1635423883934; Thu, 28 Oct 2021 05:24:43 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:3c03:6478:21a3:2901:16a6? ([2804:7f0:4841:3c03:6478:21a3:2901:16a6]) by smtp.gmail.com with ESMTPSA id r44sm1106581otv.39.2021.10.28.05.24.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Oct 2021 05:24:43 -0700 (PDT) Subject: Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) To: LEROY Christophe , =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , BALATON Zoltan , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Cc: Peter Maydell , Thomas Huth , "dbarboza@redhat.com" , Alexey Kardashevskiy , "gdb@sourceware.org" , Richard Henderson , Greg Kurz , Wainer dos Santos Moschetta , QEMU Developers , Alexander Graf , qemu-ppc , =?UTF-8?Q?Herv=c3=a9_Poussineau?= , David Gibson References: <20210927044808.73391-1-david@gibson.dropbear.id.au> <20210927044808.73391-5-david@gibson.dropbear.id.au> <18fa56ee-956e-ee2f-9270-82aa96dfde09@redhat.com> <40cdb137-60c9-43fd-7b48-4858cbd9307c@redhat.com> <6c2ff4e6-4bf4-d310-5e26-c8d2741177bc@redhat.com> <42e5a8c2-b8fa-b9e2-71f1-c8e5cd7f5cef@csgroup.eu> <1397f18f-f187-6f48-ed6c-13c0b77abed9@redhat.com> <9aeb7010-0a17-864a-cfac-ea5d90356085@csgroup.eu> <5e4f78ce-1508-5689-ec29-79edad0c824e@kaod.org> <491d6265-3785-b11-b7f0-621a3d2823@eik.bme.hu> <103e098a-a8ac-a22a-8aad-3df7d8cde148@amsat.org> <939f2d12-38f6-4ab0-b688-384136d1d9c@eik.bme.hu> <4e07823e-7162-525a-4a61-9bed63e85d58@kaod.org> <5263c819-b13c-f48a-d720-15b085537070@csgroup.eu> From: Luis Machado Message-ID: <2b5f000b-31c0-bd2c-14a3-63a23f73ab18@linaro.org> Date: Thu, 28 Oct 2021 09:24:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <5263c819-b13c-f48a-d720-15b085537070@csgroup.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 12:24:46 -0000 On 10/20/21 10:16 AM, LEROY Christophe wrote: > > > Le 20/10/2021 à 14:43, Cédric Le Goater a écrit : >> On 10/20/21 13:42, BALATON Zoltan wrote: >>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote: >>>> On 10/5/21 14:29, Thomas Huth wrote: >>>>> On 05/10/2021 14.20, BALATON Zoltan wrote: >>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote: >>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote: >>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote: >>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit : >>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote: >>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote: >>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit : >>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote: >>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that >>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in >>>>>>>>>>>>>>> QEMU (as far as I >>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's >>>>>>>>>>>>>>> also not possible >>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly). >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on >>>>>>>>>>>>>> either board, by passing either a pflash or a bios argument. >>>>>>>>>>>>> >>>>>>>>>>>>> True. I did some more research, and seems like there was once >>>>>>>>>>>>> support for those boards in u-boot, but it got removed there a >>>>>>>>>>>>> couple of years ago already: >>>>>>>>>>>>> >>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf >>>>>>>>>>>>> >>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b >>>>>>>>>>>>> >>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37 >>>>>>>>>>>>> >>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody actually >>>>>>>>>>>>>> successfully using these boards for anything, so we should >>>>>>>>>>>>>> deprecate-and-delete them. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still >>>>>>>>>>>>> uses >>>>>>>>>>>>> them and speaks up, we can still revert the deprecation again. >>>>>>>>>>>> >>>>>>>>>>>> I really would like to be able to use them to validate Linux >>>>>>>>>>>> Kernel >>>>>>>>>>>> changes, hence looking for that missing BIOS. >>>>>>>>>>>> >>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any >>>>>>>>>>>> regression >>>>>>>>>>>> tests of Linux Kernel on those processors. >>>>>>>>>>> >>>>>>>>>>> If you/someone managed to compile an old version of u-boot for >>>>>>>>>>> one of these >>>>>>>>>>> two boards, so that we would finally have something for >>>>>>>>>>> regression testing, >>>>>>>>>>> we can of course also keep the boards in QEMU... >>>>>>>>>> >>>>>>>>>> I can see that it would be usefor for some cases, but unless >>>>>>>>>> someone >>>>>>>>>> volunteers to track down the necessary firmware and look after >>>>>>>>>> it, I >>>>>>>>>> think we do need to deprecate it - I certainly don't have the >>>>>>>>>> capacity >>>>>>>>>> to look into this. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I will look at it, please allow me a few weeks though. >>>>>>>> >>>>>>>> Well, building it was not hard but now I'd like to know what board >>>>>>>> QEMU actually emulates, there are way too many codenames and PVRs. >>>>>>> >>>>>>> yes. We should try to reduce the list below. Deprecating embedded >>>>>>> machines >>>>>>> is one way. >>>>>> >>>>>> Why should we reduce that list? It's good to have different cpu >>>>>> options when one wants to test code for different PPC versions (maybe >>>>>> also in user mode) or just to have a quick list of these at one place. >>>>> >>>>> I think there are many CPUs in that list which cannot be used with any >>>>> board, some of them might be also in a very incomplete state. So >>>>> presenting such a big list to the users is confusing and might create >>>>> wrong expectations. It would be good to remove at least the CPUs which >>>>> are really completely useless. >>>> >>>> Maybe only remove some from system emulation but keep all of them >>>> in user emulation? >>> >>> Or keep them all but mark those that are not tested/may be incomplete? >>> So the used can see what is expected to work and what may need to be >>> fixed. That way somebody may try and fix it whereas if it's not there >>> they are unlikely to try to add it. >> >> >> The bamboo machine with 440 CPUs is booting with the latest kernel >> and we have an acceptance test for it now, thanks to Thomas. There >> is not much effort in keeping them in a working state until someone >> volunteers. Hopefully, Christophe is making sure that we are not >> breaking anything with Linux support. >> >> The 405 machine are still close to deprecation I think. We are still >> struggling to boot one with mainline Linux, using uboot provided by >> Thomas which skips SDRAM init. It is not clear to me if u-boot is >> strictly necessary. It depends if Linux relies on it to do some >> pre-initialization of HW. I guess once we find a good DTS for it, or >> not, we can take a decision. >> > > I now have a hacked configuration booting linux with the hotfoot DTS and > the kernel is booting up to starting /init > > Then it is faulting forever taking a DSI for write protection. The > problem is now likely in Linux and I'm investigating it, but I'm having > problem with GDB (7.8.1), I'm hitting the bug > https://sourceware.org/bugzilla/show_bug.cgi?id=17700 > > And GDB 11.1 coredumps while reading vmlinux's symbols > > Hopefully I'll find a GDB version between 7.8 and 11 that works. > Just to confirm, you're not really having problems with the ARM port of GDB, right? It is a 32-bit PowerPC one. The bug you pointed out is only a reference to a similar one for PowerPC?