mender on intel

[Nick Drew]

Hi all

Experience level: novice - I'm just researching yocto, OE, etc. I've run the mender 1.2 tutorial - deploying the demo QEMU image in docker, etc.

I currently run a bunch of kiosks with a mix of 32 and 64 bit windows, but as we scale out they are getting increasingly hard to manage.  We're putting together a plan to shift to linux.  Mender.io looks like it could be a good part of this strategy.

We'd like to continue to leverage our existing hardware - e.g. ia32 and x64, usb3, VPNs, etc. There's not much visibility in the mender on intel space that I can see.   I see there are custom yocto layers for mender on rpi.  Is there a similar effort for mender-intel?

What would you recommend to get up to speed quickly?

Many thanks

Nick

[gregorio....@northern.tech]

Hi Nick,

actually, there is some work currently being done on supporting x86, you can follow the work here: https://tracker.mender.io/browse/MEN-1332

Thanks,

Greg

[Dan Walkes]

I'm interested in this topic, for the purpose of migrating a legacy x86 implementation without UEFI support.

I've looked through a few of the tracker topics on the mender forum linked to https://tracker.mender.io/browse/MEN-1332 and don't completely understand them yet but I have an idea for implementing which doesn't appear to match the options researched there.

I was curious if anyone has investigated whether it would be possible to run u-boot as a payload from an existing bootloader with good support for x86.  For instance, syslinux has an elf.32 module [1] which can load elf files, and grub has support for several different kernels [2] in elf format.

In addition, u-boot has a coreboot option for X86 which can load u-boot as an elf payload.  See [3] and [4] for history and [5] for details about current support.

Coreboot has limited support for hardware platforms, but I'm wondering if the coreboot payload implementation could be used with either syslinux or grub using existing modules or by extending existing modules.  The benefit would be that mender platforms on Intel could leverage the work that's gone into u-boot on ARM already.  It seems like u-boot could then be used on x86 for the purpose of selecting the boot kernel through interaction with userspace as is done on ARM and not necessarily as a full BIOS replacement on x86.

I did a really simple experiment with u-boot, qemu, and syslinux based on [6] to illustrate what I'm suggesting.  Of course it doesn't work (yet) but this should help explain what I'm thinking should be possible.

Setup syslinux boot for x86 qemu:

qemu-img create -f raw testing.img 10M
sudo apt-get install extlinux
mkfs -t ext4 testing.img
sudo mount testing.img /media/syslinux
sudo extlinux --install /media/syslinux/
sudo cp /usr/lib/syslinux/modules/bios/menu.c32 /media/syslinux/
sudo cp /usr/lib/syslinux/modules/bios/elf.c32 /media/syslinux/
sudo cp /usr/lib/syslinux/modules/bios/libcom32.c32 /media/syslinux/sudo cp /usr/lib/syslinux/modules/bios/libutil.c32 /media/syslinux/

Build u-boot coreboot payload:

make coreboot-x86_defconfig
make all
cp u-boot /media/syslinux

Setup syslinux to boot u-boot payload as elf in /media/syslinux/extlinux.conf:

UI menu.c32
LABEL boot_uboot
MENU LABEL Boot to uboot
COM32 elf.c32
APPEND /u-boot

Boot with qemu using:

qemu-system-i386 -drive file=testing.img,format=raw

This crashes after attempting to boot the elf file with:

qemu: fatal: Trying to execute code outside RAM or ROM at 0xd7fc0039

Presumably because the execution environment for u-boot is not setup properly and there needs to be relevant changes to either u-boot or syslinux to support. I suspect there's some hints about setting up correctly in [3] and the mailing lists for u-boot, syslinux, or grub might offer some additional/better suggestions.

I'm a relative novice in area of x86 bootloaders so I might be missing some obvious reason this won't work. However I'd be interested to know what it is and whether people who understand this better than I do have already eliminated this approach as a solution for reasons I don't understand.

Thanks for reading!

Dan

References:
[1] https://github.com/joyent/syslinux/blob/master/com32/modules/elf.c
[2] https://www.gnu.org/software/grub/manual/grub/grub.html#Supported-kernels
[3] https://blogs.coreboot.org/blog/2011/04/30/u-boot-as-coreboot-payload/
[4] https://mail.coreboot.org/pipermail/coreboot/2011-May/064914.html
[5] http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.x86
[6] http://www.syslinux.org/wiki/index.php?title=Development/Testing

[Kristian Amlie]

I think the approach is generally sound, but I suspect that it may be an
uncommon scenario which is rarely tested and might therefore be broken.
Boot loaders are quite sensitive to changes in the environment in which
they run.

For sure ELF support is not completely broken, because we use it to run
our QEMU ARM emulation, but whether the same is true on x86 is
uncertain. I tried to run U-Boot as a payload under x86/UEFI a while
back, but this was unsuccessful, so it may be that x86 is not receiving
as much love as ARM is, and is therefore more prone to breakage.

I'm afraid I can't provide much detail about *what* exactly could be
broken; this is outside my area of expertise as well.

--
Kristian

[Dan Walkes]

I'm afraid I can't provide much detail about *what* exactly could be
broken; this is outside my area of expertise as well. 

Thanks Kristian,

I've made a bit more progress with u-boot + grub2 multiboot and posted a request for comment on the u-boot mailing list at https://lists.denx.de/pipermail/u-boot/2017-November/312574.html.

[Dan Walkes]

I've found crickets on the u-boot mailing list as you can see.

I've noticed at least two problems with this approach after further research on my own.

1) It appears u-boot doesn't have support for setting up memory ranges based on the multiboot standard and grub memory map as described at [1].  This probably would not be too difficult to add.

2) I think u-boot would need to support the multiboot standard for video as described at [2] in a video framebuffer driver similar to what they did was done for coreboot at [3].  This would take more research/effort.

I'm not sure what would be left after this but it definitely appears difficult enough to make modifying grub a better option.  My guess is that the grub boot option mentioned at [4] is not useful on its own, only for the purposes of developing driver support within u-boot.

Congratulations on the 1.5 release with Intel support ([5])!  I haven't looked into this in detail yet but if I understand correctly from the press release folks like me who are unfortunate enough to need to support legacy platforms which aren't booting UEFI but legacy BIOS are still out of luck, is that accurate?

[1] https://wiki.osdev.org/Detecting_Memory_(x86)

[2] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Top

[3] https://github.com/u-boot/u-boot/blob/master/drivers/video/coreboot.c

[4] https://lists.denx.de/pipermail/u-boot/2011-November/108932.html

[5] https://mender.io/blog/mender-1-5-beta-intel-x86-support

[Eystein Måløy Stenberg]

On 17/05/18 06:32, Dan Walkes wrote:> Congratulations on the 1.5 release

with Intel support ([5])!  I haven't
> looked into this in detail yet but if I understand correctly from the
> press release folks like me who are unfortunate enough to need to
> support legacy platforms which aren't booting UEFI but legacy BIOS are
> still out of luck, is that accurate?

Thanks, we are glad you like the direction. We are focusing on
broadening Mender so more people can take advantage of OTA updates.

Regarding BIOS-based devices, you are correct that you are still out of
luck, but not for long. We have an implementation plan for supporting
these too and you should see support here in a month or so. If you have
an account in the issue tracker you can watch this issue (and "Issues in
Epic"): https://tracker.mender.io/browse/MEN-1846

Feedback and testing is welcome!

>
> [1] https://wiki.osdev.org/Detecting_Memory_(x86)
> [2] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Top
> [3] https://github.com/u-boot/u-boot/blob/master/drivers/video/coreboot.c
> [4] https://lists.denx.de/pipermail/u-boot/2011-November/108932.html
> [5] https://mender.io/blog/mender-1-5-beta-intel-x86-support
>

> --
> You received this message because you are subscribed to the Google
> Groups "Mender List mender.io" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mender+un...@lists.mender.io
> <mailto:mender+un...@lists.mender.io>.
> To post to this group, send email to men...@lists.mender.io
> <mailto:men...@lists.mender.io>.
> Visit this group at
> https://groups.google.com/a/lists.mender.io/group/mender/.

--

Eystein

[Dan Walkes]

On Thursday, May 17, 2018 at 11:38:12 AM UTC-6, Eystein Stenberg wrote:

On 17/05/18 06:32, Dan Walkes wrote:> Congratulations on the 1.5 release
with Intel support ([5])!  I haven't
> looked into this in detail yet but if I understand correctly from the
> press release folks like me who are unfortunate enough to need to
> support legacy platforms which aren't booting UEFI but legacy BIOS are
> still out of luck, is that accurate?

Thanks, we are glad you like the direction. We are focusing on
broadening Mender so more people can take advantage of OTA updates.

Regarding BIOS-based devices, you are correct that you are still out of
luck, but not for long. We have an implementation plan for supporting
these too and you should see support here in a month or so. If you have
an account in the issue tracker you can watch this issue (and "Issues in
Epic"): https://tracker.mender.io/browse/MEN-1846

Great!  Thanks for the update Eystein.  I did sign up for an account in the issue tracker but I'm still seeing permission denied on that particular issue at the moment.  

This issue can't be viewed

The issue you're trying to view can't be displayed.
It may have been deleted or you don't have permission to view it right now.

 

A search for "BIOS" turns up only https://tracker.mender.io/browse/MEN-1117 with my login.  

Feedback and testing is welcome!

OK great, I would like to participate and will spend some time getting acquainted with the latest changes, which presumably will be referenced in https://tracker.mender.io/browse/MEN-1846 once I have access?

[Eystein Måløy Stenberg]

On 17/05/18 15:53, Dan Walkes wrote:> Great!  Thanks for the update

Eystein.  I did sign up for an account in
> the issue tracker but I'm still seeing permission denied on that
> particular issue at the moment.
>
>
> This issue can't be viewed
>
> The issue you're trying to view can't be displayed.
> It may have been deleted or you don't have permission to view it right now.
>
> A search for "BIOS" turns up
> only https://tracker.mender.io/browse/MEN-1117 with my login.

Sorry about that, it was misconfigured. I fixed it now, so you should
see it.

>
> Feedback and testing is welcome!
>
>
> OK great, I would like to participate and will spend some time getting
> acquainted with the latest changes, which presumably will be referenced
> in https://tracker.mender.io/browse/MEN-1846
> <https://tracker.mender.io/browse/MEN-1846> once I have access?

Awesome! Yes and would also watch the two "Issues in Epic" there:
https://tracker.mender.io/browse/MEN-1845 and
https://tracker.mender.io/browse/MEN-1847 for more detailed tracking.