Steve's blog

I've spent more time on the integration of 32-bit grub-efi with a 64-bit Debian system, and just published a new test image on pettersson. I've added:

a patch to the Linux kernel to add a new /sys file which exposes the size of the underlying UEFI platform (32- or 64-bit).
a patch to grub2 to read that new /sys file in grub-install to determine the right version of grub-efi to install by default
a patch to grub-installer to do similar

These remove the manual steps that were necessary for a 64-bit installation with the previous build. I've just used this exact image (and a network mirror) to install a fully-functional 64-bit Gnome system on the X205TA, simply by selecting "64-bit install" from the GRUB menu and following prompts. Yay! Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload3/ to download and test the image.

Now, there's no guarantee that the kernel patch I've submitted to the linux-efi folks will be accepted in its current form, and even if it is I'll have to get it and the other code I've written accepted into the various packages and then into Jessie! But for now this image should work just fine for Bay Trail folks I hope!

WARNING: this CD is provided for testing only. Use at your own risk! If you have appropriate (U)EFI hardware, please try this image and let me know how you get on, via the debian-cd and debian-boot mailing lists.

For now, I'm going to pause development here. The core code I'm using to make these images is all in the debian-cd and d-i repos, and I'll push the other patches once I know they'll work with the kernel. But I've got a slew of other things that I need to work on in the next few weeks, in no particular order:

RC bugs filed against abcde
Sorting out Mac-only 32-bit netinst images (only EFI boot? without EFI?)
Regular openstack image generation for Jessie
Regular debian-live image generation for Jessie
...

I'm currently not planning to make all of Debian's amd64 images bootable using 32-bit UEFI like this image - I'm happy to leave this as just an option for our multi-arch i386/amd64 images (netinst or DVD only). I think that's a reasonable compromise here, and it's also the easiest thing for me to do with the current debian-cd build system.

Finally, apologies if you've asked me questions about the earlier images in this series and I've not responded yet. Fixing that ASAP!

02:49 :: # :: /debian/CDs :: 22 comments

Comments

Re: UEFI Debian installer work for Jessie, part 5
Rene wrote on Mon, 02 Mar 2015 20:13

Hi Steve,

thanks for your work on this! Using http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload3/debian-jessie-UEFI-testing-netinst-i386-amd64-build3.iso I managed to install Jessie onto a Dell Venue 8 Pro tablet. The installer works almost flawlessly. Even the graphical installer, including touch input, works!

There is one glitch related to the internal eMMC flash. The kernel recently started exposing RPMB (Replay Protected Memory Block) partitions. Standard read/write operations will fail, only special IOCTLs are supported, leading to significant delays when parted is started. There is a Debian kernel bug report about this at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759656 where some commenters suggest a patch that causes unsupported operations to be silently dropped. I believe this is the wrong approach as these are indeed I/O errors. Instead, user space shouldn't attempt messing with RPMB partitions in the first place. The latter approach can apparently be implemented through modified udev rules which is discussed in this Ubuntu bug report https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1333140.

Do you see any chance of getting the latter patch into the installer images? It would make installation on Bay Trail machines a much smoother experience.

As for the installed system, there are a number of issues. Most annoyingly, the kernel fails to boot unless I enter the (firmware-provided) EFI boot menu first. Otherwise there is no output after the usual "Loading initial ramdisk" in GRUB. I suspect it may be related to the framebuffer setup or the EFI handover not working correctly, but my knowledge of EFI and early boot stages on x86 is too limited to debug this further. What would be the right place to discuss this?

Then there's obviously a lot of hardware built into the Venue 8 Pro that doesn't work out of the box. Wifi sort of works with an out-of-tree driver https://github.com/hadess/rtl8723bs. Other hardware (buttons, sound) needs extra kernel config options to be enabled. I hope I'll be able to test these with a kernel compiled from source soon. I take it I'd file wishlist bugs against linux-image if enabling the config options makes the hardware in question work?

Finally, the i915 driver appears to crash the kernel, so I'm booting with the "nomodeset i915.modeset=0" kernel parameters which causes X to fall back to the plain framebuffer driver. I'll need to investigate this further but like in the above EFI case I'd appreciate any pointers as to where to seek help with it.

One thing I'll probably do is setting up a wiki page to track bug reports/patches related to the Venue 8 Pro.

Thanks again,

Rene

Your Comment