Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1906282imu; Wed, 12 Dec 2018 06:24:24 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vfczgg08W31tge7wV2KI1bI4F+j3BKYWLluWFiSfBGUpH546SmaZQVAxlpjOkZ4MKzo0/E X-Received: by 2002:a63:5d14:: with SMTP id r20mr18524923pgb.329.1544624664909; Wed, 12 Dec 2018 06:24:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544624664; cv=none; d=google.com; s=arc-20160816; b=YyonQcDj5J3YQLe/HwgPt2tBUtic+kfPjnWHQpZn0R9neBb6hShYh42kkWaF+1FYza xWnfWchMBCWPOvOa00z6gjoMntiw7LHUJVc73h+xyb5fCtmAz5HtkmR+7KTZAOXJBFzX SHJkze3dL5GUftIqvujqzxLWhqVRtD0VvPJYEXMKfKHq0odBoFGexrpHIIzybI9+sOdt g29uWZ7Tnx6CS9ihxWb+B8MvgPZoEjxE8FBPBjYzs1c7UELEd+fxP3eL+KRQGBLhsIuI E+1GALs5fepm8xHv5pIXaXVYyuJvfW3D3BF8Jc2xsyhWu6KRJFXY9AJRRFz2wLBYUC7j BFIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=yklT69WfqJg4U9E3rKc4uQTY/OcSoiViPIQmFbPUNt0=; b=NIIP8+xhxTgp0ppurn1YumpubuHpbIvkbgRgGFpyPAafzx1/1j7kfvbGHncoGy/6IF g/7+Z4T7KjaA36YpZXb8sJun1B4ExrAmBSkthYyljK+epW7L0V0jV8kU4dBYoFmWvKNZ PmJ3Bq8pj/5oq1WrSanq+Toph4fSMB0f2Pw7+a7zH9yZy0wib/tUL1RPn47+8j16TMUu 4LHxYtkLwnRJMX3+RyZFyRCDOv64htl2mYRq8eFFmC2hShakmsZLke3NifaurstulTgr gLBTJEbEF9VwNSJUccgflsHKQd6KZ06fDXPt3YlQgeHWgZ1ndrtVdVsdbH663FD+iQvQ J5Cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=aeXe1Hkc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t130si14608362pgb.521.2018.12.12.06.24.08; Wed, 12 Dec 2018 06:24:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=aeXe1Hkc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726676AbeLLOW0 (ORCPT + 99 others); Wed, 12 Dec 2018 09:22:26 -0500 Received: from conssluserg-05.nifty.com ([210.131.2.90]:43146 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726228AbeLLOWZ (ORCPT ); Wed, 12 Dec 2018 09:22:25 -0500 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (authenticated) by conssluserg-05.nifty.com with ESMTP id wBCEM09N029152; Wed, 12 Dec 2018 23:22:01 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com wBCEM09N029152 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1544624521; bh=yklT69WfqJg4U9E3rKc4uQTY/OcSoiViPIQmFbPUNt0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aeXe1Hkc7QMrUx0W0WrPrl7jvVoX6DVSUOoKmh9LXPPOk4Va0A6GAmIIg0reAaVhR EfJzG5i9rnD3YnmNSudHscceuwCUCtxHhgi/1o6rHLO+EFguxySPWRPr756eET4Uv+ Kyt5W8iDX61fEMiUj7R3674MzzQL8g1tIDsNUZu7i4JAa3R0tmBZG+gKXVbPHrmi2Y IcRclt6N39hFvv6AlE5My3p2cUhQpTbPHcRpptoGt5H6oReyaCeeNZ2o8J1yL0c9Zr La+MLYkKwEmqelqa9G6ZUhlgtAh9dzVD+YCipqRnf6QOH6fHuSYpnszQegh0yTeXpS X3TNZnnxkxYDQ== X-Nifty-SrcIP: [209.85.222.47] Received: by mail-ua1-f47.google.com with SMTP id j3so6489565uap.3; Wed, 12 Dec 2018 06:22:01 -0800 (PST) X-Gm-Message-State: AA+aEWaHEJHZv4P8oTfrYDcmPcMSJcRgOWEqHsp4JQHsnk7mVOJFOr0U vFDyw/LA1i1yJuQYlIsgK20vkXRQ1ysEo/YnAfo= X-Received: by 2002:ab0:849:: with SMTP id b9mr5739948uaf.93.1544624519796; Wed, 12 Dec 2018 06:21:59 -0800 (PST) MIME-Version: 1.0 References: <1543823457-32478-1-git-send-email-yamada.masahiro@socionext.com> <19c7bdab-8df8-f7c6-7921-9a4d43dbca64@monstr.eu> <938f1368-5e07-0178-5b99-d8331ce216f8@xilinx.com> <18fb7c8b-2b47-eb39-d80b-7137e7db466b@xilinx.com> <44c60aca-c9de-8459-aefa-5d95111f8e8e@xilinx.com> In-Reply-To: From: Masahiro Yamada Date: Wed, 12 Dec 2018 23:21:23 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/7] microblaze: fix various problems in building boot images To: Michal Simek Cc: Michal Simek , Linux Kbuild mailing list , DTML , Linux Kernel Mailing List , Rob Herring , Mark Rutland Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 12, 2018 at 11:11 PM Masahiro Yamada wrote: > > On Wed, Dec 12, 2018 at 10:50 PM Michal Simek wrote: > > > > On 08. 12. 18 7:14, Masahiro Yamada wrote: > > > On Sat, Dec 8, 2018 at 12:20 AM Michal Simek wrote: > > >> > > >> On 07. 12. 18 14:29, Michal Simek wrote: > > >>> On 07. 12. 18 12:29, Masahiro Yamada wrote: > > >>>> On Thu, Dec 6, 2018 at 11:55 PM Michal Simek wrote: > > >>>>> > > >>>>> On 03. 12. 18 8:50, Masahiro Yamada wrote: > > >>>>>> This patch set fixes various issues in microblaze Makefiles. > > >>>>>> > > >>>>>> BTW, "simpleImage.
" works like a phony target to generate the > > >>>>>> following four images, where the first three are just aliases. > > >>>>>> > > >>>>>> - arch/microblaze/boot/simpleImage.
: > > >>>>>> identical to arch/microblaze/boot/linux.bin > > >>>>>> > > >>>>>> - arch/microblaze/boot/simpleImage.
.unstrip: > > >>>>>> identical to vmlinux > > >>>>>> > > >>>>>> - arch/microblaze/boot/simpleImage.
.ub: > > >>>>>> identical to arch/microblaze/boot/linux.bin.ub > > >>>>>> > > >>>>>> - arch/microblaze/boot/simpleImage.
.strip: > > >>>>>> stripped vmlinux > > >>>>>> > > >>>>>> I am not sure how much useful those copies are, > > >>>>>> but, I tried my best to keep the same behavior. > > >>>>>> > > >>>>>> IMHO, I guess DTB=
would be more sensible, > > >>>>>> but it is up to Michal. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Masahiro Yamada (7): > > >>>>>> microblaze: fix cleaning of boot images > > >>>>>> microblaze: adjust the help to the real behavior > > >>>>>> microblaze: move "... is ready" message to arch/microblaze/Makefile > > >>>>>> microblaze: fix multiple bugs in arch/microblaze/boot/Makefile > > >>>>>> microblaze: add linux.bin* and simpleImage.* to PHONY > > >>>>>> microblaze: fix race condition in building boot images > > >>>>>> microblaze: remove the unneeded code just in case file copy fails > > >>>>>> > > >>>>>> arch/microblaze/Makefile | 14 +++++++++----- > > >>>>>> arch/microblaze/boot/Makefile | 33 +++++++++++++++++---------------- > > >>>>>> arch/microblaze/boot/dts/Makefile | 5 +---- > > >>>>>> 3 files changed, 27 insertions(+), 25 deletions(-) > > >>>>>> > > >>>>> > > >>>>> One more thing I have in my mind for a while is that will be good to > > >>>>> configure kernel build flags from DT and completely get rid of these > > >>>>> symbols. > > >>>>> > > >>>>> XILINX_MICROBLAZE0_USE_MSR_INSTR > > >>>>> XILINX_MICROBLAZE0_USE_PCMP_INSTR > > >>>>> XILINX_MICROBLAZE0_USE_BARREL > > >>>>> XILINX_MICROBLAZE0_USE_DIV > > >>>>> XILINX_MICROBLAZE0_USE_HW_MUL > > >>>>> XILINX_MICROBLAZE0_USE_FPU > > >>>>> > > >>>>> It means setup CPUFLAGS based on extracting that values from DT that it > > >>>>> all the time match the hardware. > > >>>>> It will also simplify all the CPUFLAGS logic which is in > > >>>>> arch/microblaze/Makefile. > > >>>>> > > >>>>> Do you have any idea how this can be done? > > >>>> > > >>>> > > >>>> I have no idea. > > >>>> > > >>>> Parsing DTS with sed or something would be possible, but ugly. > > >>>> > > >>>> In my opinion, the kernel should be multi platform image, > > >>>> in other words, it is the least common denominator > > >>>> of supported platforms. > > >>>> > > >>>> So, the kernel should enable all features that may or may not be used > > >>>> depending on platform. > > >>>> > > >>>> I do not know if this works for MB. > > >>> > > >>> Microblaze is soft core CPU where you can select if you want to have it > > >>> with multiplier, divider, barrel shifter, etc. > > >>> You can of course say that you don't have them and you have "universal" > > >>> kernel but very slow. > > >>> That's why user has to setup these configs which are converted to cflags > > >>> to say GCC what can be used. > > >>> And these configs can be simply parsed from dt. > > >>> > > >>> For example like this based on dtb (quick hack) > > >>> > > >>> for i in `echo use-msr-instr use-pcmp-instr use-barrel use-div > > >>> use-hw-mul use-fpu`; do > > >>> UPPER=`echo $i | tr '-' '_' | tr '[a-z]' '[A-Z}'` > > >>> echo $i $UPPER; > > >>> > > >>> VAR=`fdtget -t i $FILE/arch/microblaze/boot/dts/system.dtb /cpus/cpu@0/ > > >>> xlnx,$i` > > >>> FLAGS+="CONFIG_XILINX_MICROBLAZE0_${UPPER}=${VAR} " > > >>> done > > >>> > > >>> make $FLAGS > > >>> > > >>> > > >>> When simpleImage is requested dt could be parsed to setup proper build > > >>> flags. > > >> > > >> One more thing I found is that I have done these changes > > >> > > >> diff --git a/arch/microblaze/kernel/setup.c b/arch/microblaze/kernel/setup.c > > >> index bbd6968ce55b..dc6a6fee3ae2 100644 > > >> --- a/arch/microblaze/kernel/setup.c > > >> +++ b/arch/microblaze/kernel/setup.c > > >> @@ -153,11 +153,13 @@ void __init machine_early_init(const char > > >> *cmdline, unsigned int ram, > > >> #endif > > >> > > >> #if CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR > > >> +#error MSR is enabled > > >> if (msr) { > > >> pr_info("!!!Your kernel has setup MSR instruction but "); > > >> pr_cont("CPU don't have it %x\n", msr); > > >> } > > >> #else > > >> +#error MSR is not enabled > > >> if (!msr) { > > >> pr_info("!!!Your kernel not setup MSR instruction but "); > > >> pr_cont("CPU have it %x\n", msr); > > >> > > >> and run MSR with 1 > > >> make defconfig && make CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1 > > >> arch/microblaze/kernel/setup.o > > >> it errors #error MSR is enabled > > >> and all is good. > > >> > > >> And when I run MSR with 0 > > >> make defconfig && make CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=0 > > >> arch/microblaze/kernel/setup.o > > >> also getting #error MSR is enabled > > >> which is wrong. > > >> > > >> Is there any rule what can be setup at compilation time? > > > > > > You are trying to do very specific things, > > > I do not have a clean solution. > > > > > > I do not mind whatever you do in arch-Makefile. > > > > ok. > > > > > > > > If you look at stack_protector_prepare in arch/powerpc/Makefile, > > > it is parsing a file with awk to setup compiler flags. > > > > Ok. Will do more experiments with it. > > > > Can you please at least confirm me that config options passed via > > command line as above should be used instead of that one in .config? > > (Just want to understand why USE_MSR is so special that it is not > > working properly). > > > > > make defconfig && make CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1 > > does not work. > > It overrides only references in Makefiles. > > > > C files still refer to include/generated/autoconf.h > which is created based on Kconfig. > > > KBUILD_CPPFLAGS += > -DCONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=$(CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR) > > might work although it is ugly. > > (At least, CONFIG_ prefix should be ripped off) Perhaps, another idea might be merge_config. arch/mips/Makefile manipulates .config by using scripts/kconfig/merge_config.sh You can enable/disable CONFIG_XILINX_MICROBLAZE0_USE* based on the information extracted from DT. -- Best Regards Masahiro Yamada