From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6927512860892332032 X-Received: by 2002:a7b:c95a:: with SMTP id i26mr3171322wml.164.1612967025500; Wed, 10 Feb 2021 06:23:45 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:2ecd:: with SMTP id u196ls1015789wmu.1.gmail; Wed, 10 Feb 2021 06:23:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJzjPEkmc6SJa55kQHeeJjjzNZjr9sEM5kJ+hJh11clKUmI7ZbZOHHVIbXZgxmrkVS0Fyod+ X-Received: by 2002:a1c:f312:: with SMTP id q18mr3152321wmq.79.1612967024661; Wed, 10 Feb 2021 06:23:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612967024; cv=none; d=google.com; s=arc-20160816; b=kGhWykSWVzXN62d7zZQseJCsQA/KyFA3RJGf2Z0jAPuINCSxkLeTy2BxOAoCeLe8M6 jSkwvZUK4x+Z7V9GYI3obLBxGrs1lPMaS0EqzVBPmbzQn0IKvJUVkZOLCmM8PHffGAxN NA9H80WZXOSXehZ+Gw0lqIaeokCj7re0wFwzXN3mK+E9ty5JTNTviv5Kfyrgm859vAQ5 s5Zh1OBxhN6s1pS7smxWZ2/9BZPbiOV6zjlquvVKmzgeoAeaW6UB0N9xu8m5TTxOdCFQ 43uUKc38PNCGCRfxIGmWlc8m+wG/L5tA+27dqT9Zx4De7j2hyR+Z9aWJ+QOigeL0cWeb ApIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=X/dzu6c8BndoxzI5CKDbZURUspSFm+qBFAelKC+kcno=; b=UaXXCB20Syc4VNzZd9A03u8R0egsPXU91Ad9PnUnLmjoSm3Pivcfla1GY3XMCkSqtp TohOUsKn1t5oKZhk2Frja97RbBUHOTxp2y/svHXJfHMpVCoNIhePh8HCSkhA/rdPUlFS W+II1hbrvRCPCRRlNorpthUYNr1RiwO9pBa+7+TcqcU+PypmuCfbjii479T3aHLFUWNe z3kkPblzhUH9/NSa9CGo8mzO6yOBVX9gfYClQ/Q7//C0ic2WBB07Ddz3y9bDEbUcAAvh FvDIQf2OVXpt4LtoosPHB+i2MUjNEO/Ded1mGyMoMIvz77dk0+fusiQ7M9bgDvmv70pZ hzMw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id n13si134022wro.2.2021.02.10.06.23.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Feb 2021 06:23:44 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 11AENi9f018189 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Feb 2021 15:23:44 +0100 Received: from md1za8fc.ad001.siemens.net ([139.22.126.201]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 11AENhdE015251; Wed, 10 Feb 2021 15:23:44 +0100 Date: Wed, 10 Feb 2021 15:23:43 +0100 From: Henning Schild To: Daniel Machon Cc: Baurzhan Ismagulov , "isar-users@googlegroups.com" Subject: Re: Support for generating bootx64.efi when distro arch is i386 Message-ID: <20210210152343.485795c3@md1za8fc.ad001.siemens.net> In-Reply-To: References: <86fa58d19dba43d2950b99d6d25067a3@universal-robots.com> <20210210085616.GU20742@yssyq.m.ilbers.de> <20210210114244.439de40a@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: MX+ZUZFf0HT0 Am Wed, 10 Feb 2021 13:14:25 +0000 schrieb Daniel Machon : > It is indeed implemented in a separate layer. Ok than it should not be too hard for you to maintain it on your end, if it does not end up in Isar. > In this particular case, it is only a question of being able to, > explicitly, choose between i386/amd64 or arm64/arm32 grub images. I > am not quite sure this can be implemented in a more generic way, than > just introducing a variable, say FIRMWARE_ARCH, that defaults to > DISTRO_ARCH - do you have anything in mind, Henning? bootimg-efi-isar is a fork of bootimg-efi from openembedded, a fork that should be more "glue" than features So in fact the feature should be proposed in OE and isar would inherit it at some point in time. Would i would try to do for this kind of exotic feature is try and use dpkg-divert to have apt exchange the files for you. The package configuring apt would have to be installed in the buildchroot before grub is installed there. So you would end up with a raw package placing a few apt conf files, which becomes an imager depends. Such things are board support and are found in many layers. If you ever want robust firmware update you will fast find yourself dumping grub and going for https://github.com/siemens/efibootguard or systemd, or u-boot https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/master/recipes-bsp/efibootguard I guess you can cross compile this from i386 to amd64 ... and be done. Looking at real product layers grub is hardly ever used, and in the efi case the systemd path does not seem to have the DISTRO_ARCH switch-case. It might be valuable but you might also find yourself wanting to ditch grub. Efi has some sort of chainloading, that is how we hook our watchdogs into systemd booting, maybe that can be used to load that 32bit efi binary from debian from another 64bit one you prepend in a customer imager step. regards, Henning > > My guess would be legacy applications. And my suggestion would be > > ... full on 64bit and just have the problematic applications be > > 32bit > > It is indeed about legacy applications that needs to run in a 32bit > userspace context. Normally you would go with a multilib solutions to > support the 32bit applications in a 64bit userspace, however, for > specific (backwards compatibility) reasons, this is not a possibility. > > / Daniel > > Med venlig hilsen / Best regards > > Daniel Machon > Embedded Linux Engineer > R&D Department > [cid:UR_New_Logo_266cf885-8c99-4fe9-bae0-ff88fedf0005.png] > > Universal Robots A/S > Energivej 25 > 5260 Odense S > > Phone: +45 89 93 89 89 > Cell: +45 27 99 72 32 > > dama@universal-robots.com > www.universal-robots.com > > > > Please note that this message may contain confidential information. > If you have received this message by mistake, please inform the > sender of the mistake, then delete the message from your system > without making, distributing or retaining any copies of it. Although > we believe that the message and any attachments are free from viruses > and other errors that might affect the computer or IT system where it > is received and read, the recipient opens the message at his or her > own risk. We assume no responsibility for any loss or damage arising > from the receipt or use of this message. > > If Universal Robots A/S processes personal data relating to physical > persons, such processing will meet the requirements of applicable > data protection legislation.Please see our Privacy Policy > here. > > > -----Original Message----- > From: isar-users@googlegroups.com On > Behalf Of Henning Schild Sent: 10. februar 2021 11:43 > To: Baurzhan Ismagulov > Cc: isar-users@googlegroups.com > Subject: Re: Support for generating bootx64.efi when distro arch is > i386 > > > CAUTION - EXTERNAL EMAIL: Do not open attachments or links unless you > recognize the sender and the content is safe. > > > Am Wed, 10 Feb 2021 09:56:16 +0100 > schrieb Baurzhan Ismagulov : > > > Hello Daniel, > > > > On Tue, Feb 09, 2021 at 08:45:06PM +0000, Daniel Machon wrote: > > > Would you consider a patch series that adds support for separating > > > the DISTRO_ARCH from the generation of the grub image? > > > > > > We have a use case where target userland is i386, but firmware > > > only supports loading of 64bit EFI executables. Currently the > > > DISTRO_ARCH is also used to generate the grub image - if distro > > > arch is i386, then grub image is bootia32.efi. > > > > > > We fixed this by introducing a new variable used (in > > > bootimg-efi-isar.py) to separately decide the grub image. > > > > IIRC, we've already had a similar use case (mixing i386 and amd64 > > userland), so this one could be interesting as well. In any case, > > I'm looking forward to the patches and discussion. > > I would not be against it but maybe as a more generic mixing pattern > than just that one. > > For your current hack you should be able to do all that in a layer > instead of touching isar ... in case you are patching it. > > > Why do you want to have i386 userland on amd64? > > My guess would be legacy applications. And my suggestion would be ... > full on 64bit and just have the problematic applications be 32bit > > Isar has support for this via ISAR_ENABLE_COMPAT_ARCH where "i386" is > the little brother of "amd64". Similar for arm32 and 64. > > Henning > > > With kind regards, > > Baurzhan. > > > > -- > You received this message because you are subscribed to the Google > Groups "isar-users" group. To unsubscribe from this group and stop > receiving emails from it, send an email to > isar-users+unsubscribe@googlegroups.com. To view this discussion on > the web visit > https://groups.google.com/d/msgid/isar-users/20210210114244.439de40a%40md1za8fc.ad001.siemens.net.