It is indeed implemented in a separate layer.

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?

> 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

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 <isar-users@googlegroups.com> On Behalf Of Henning Schild
Sent: 10. februar 2021 11:43
To: Baurzhan Ismagulov <ibr@radix50.net>
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 <ibr@radix50.net>:

> 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.