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=-6.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 035AEC433E7 for ; Wed, 14 Oct 2020 09:49:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB579207C3 for ; Wed, 14 Oct 2020 09:49:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727378AbgJNJtN (ORCPT ); Wed, 14 Oct 2020 05:49:13 -0400 Received: from [157.25.102.26] ([157.25.102.26]:36782 "EHLO orcam.me.uk" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726491AbgJNJtN (ORCPT ); Wed, 14 Oct 2020 05:49:13 -0400 Received: from bugs.linux-mips.org (eddie.linux-mips.org [IPv6:2a01:4f8:201:92aa::3]) by orcam.me.uk (Postfix) with ESMTPS id 8FE2A2BE086; Wed, 14 Oct 2020 10:49:08 +0100 (BST) Date: Wed, 14 Oct 2020 10:49:05 +0100 (BST) From: "Maciej W. Rozycki" To: Serge Semin cc: Geert Uytterhoeven , Mike Rapoport , Ralf Baechle , Paul Burton , James Hogan , Andrew Morton , Michal Hocko , Greg Kroah-Hartman , Thomas Bogendoerfer , Huacai Chen , Stefan Agner , Stephen Rothwell , Alexandre Belloni , Juergen Gross , linux-mips@vger.kernel.org, Linux Kernel Mailing List , Atsushi Nemoto Subject: Re: [PATCH 04/12] mips: Reserve memory for the kernel image resources In-Reply-To: <20190522135422.q6w7lcvh5fgpf7a5@mobilestation> Message-ID: References: <20190423224748.3765-1-fancer.lancer@gmail.com> <20190423224748.3765-5-fancer.lancer@gmail.com> <20190521155309.GB24470@rapoport-lnx> <20190522080802.GA31930@rapoport-lnx> <20190522133402.duhybxf66oubx6ng@mobilestation> <20190522135422.q6w7lcvh5fgpf7a5@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Wed, 22 May 2019, Serge Semin wrote: > > > The problem might be fixed there by the next patch: > > > --- > > > diff --git a/arch/mips/dec/prom/memory.c b/arch/mips/dec/prom/memory.c > > > index 5073d2ed78bb..5a0c734b5d04 100644 > > > --- a/arch/mips/dec/prom/memory.c > > > +++ b/arch/mips/dec/prom/memory.c > > > @@ -91,29 +91,14 @@ void __init prom_meminit(u32 magic) > > > pmax_setup_memory_region(); > > > else > > > rex_setup_memory_region(); > > > -} > > > - > > > -void __init prom_free_prom_memory(void) > > > -{ > > > - unsigned long end; > > > - > > > - /* > > > - * Free everything below the kernel itself but leave > > > - * the first page reserved for the exception handlers. > > > - */ > > > > > > #if IS_ENABLED(CONFIG_DECLANCE) > > > /* > > > - * Leave 128 KB reserved for Lance memory for > > > - * IOASIC DECstations. > > > + * Reserve 128 KB for Lance memory for IOASIC DECstations. > > > * > > > * XXX: save this address for use in dec_lance.c? > > > */ > > > if (IOASIC) > > > - end = __pa(&_text) - 0x00020000; > > > - else > > > + memblock_reserve(__pa_symbol(&_text), 0x00020000); > > > > Shouldn't that be > > > > memblock_reserve(__pa_symbol(&_text) - 0x00020000, 0x00020000); > > > > ? > > > > Right. Thanks. The updated version of the patch is attached to this email. > > -Sergey > > > > #endif > > > - end = __pa(&_text); > > > - > > > - free_init_pages("unused PROM memory", PAGE_SIZE, end); > > > } > > > --- > > > > > > Didn't wanna use prom_FREE_prom_memory to actually reserve a memory > > > chunk, so I moved the reservation into the prom_meminit() method. > > > > I guess Maciej will test this on real hardware, eventually... I finally got to it as I was hit by it the hard way (and I do have kept the thread in my inbox!), however this is the wrong fix. With DEC hardware the whole 128KiB region is reserved as firmware working memory area and we call into the firmware throughout bootstrap on several occasions. Therefore we have to stay away from it until we know we won't need any firmware services any longer, which is at this point. So this piece has to stay, and the removed reservation has to be reinstated in platform code. I'll be posting a fix separately. NB I suspect CFE platforms may need a similar fix, but I don't have access to my SWARM now, so I'll verify it on another occasion. Other platforms may need it too; at least up to a point an assumption was the kernel load address is just at the end of any firmware working area typically allocated right beyond the exception vector area, hence the reservation. I realise the assumption may have changed at one point and the oldtimers who have known it may have been away or not paying enough attention while the newcomers did not realise that. Maciej