[02:20] <DHR> I think that it is really important to build a 32-bit UEFI installer.  There are a tonne of new 32-bit only tablets and netbooks that require UEFI.  It is a shame that no mainstream Linux distro can be installed on them
[02:21] <DHR> Here's an unofficial Fedora for at least the Asus T100 and the Dell Venue 8 Pro.
[02:21] <DHR> What prompts me to come here is http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/
[02:21] <DHR> Is there a better place for me to raise this point?
[15:50] <DHR> Is this the right place to advocate for a 32-bit UEFI installation method?
[16:09] <xnox> DHR: sure.
[16:09] <xnox> DHR: most of those are 64-bit CPUs though, thus what we really need/want is to enable dual-installation of 32-bit UEFI and 64-bit UEFI on the installation media
[16:09] <xnox> and correctly detecting that uefi-arch.
[16:10] <xnox> however most of the new generation stuff is actually using 64-bit uefi these days.
[16:10] <xnox> "There are a tonne of new 32-bit" - you mean like with new atom SoCs? e.g. latest atom SoCs should be using 64-bit uefi in fact.
[16:12] <cjwatson> We already know about the 32-bit UEFI need, thanks
[16:12] <cjwatson> The advocacy has been heard and the very meeting that you linked to above included some ideas on progressing things
[16:13]  * xnox will rewatch that video
[16:13] <xnox> my understanding is that 32-bit uefi is on the decline after a short usage on certain systems. I might be wrong though.
[16:15] <DHR> I know as a consumer that there are a whole raft of new 32-bit uefi systems, mostly tablets.  It might be a passing fad, but it is really strong right now.
[16:16] <DHR> I fear that the limitation is intentional (by Intel and possibly Microsoft) and hence is not going to end with a technical solution.
[16:17] <DHR> Is it true that a 64-bit kernel cannot currently make UEFI calls (whatever that might be?  ACPI??) to a 32-bit UEFI firmware?
[16:18] <cjwatson> that's my understanding
[16:18] <cjwatson> not ACPI, UEFI Runtime Services
[16:18] <cjwatson> ICBW, that's why I flagged it as something that needed to be checked when I mentioned it in the meeting
[16:19] <DHR> Ahh.  I'll google that to understand.
[16:19] <cjwatson> if I am wrong it simplifies things :)
[16:20] <DHR> Has Intel released 64-bit UEFI firmware that does the magic power management on the atom SoCs?  It's been a year or so waiting, I think
[16:20] <cjwatson> things may have changed, e.g. https://lkml.org/lkml/2014/3/4/242
[16:20] <cjwatson> I really think that is not likely to be an installer area of expertise
[16:21] <cjwatson> #ubuntu-kernel might know better
[16:35] <xnox> DHR: cjwatson: enabling CONFIG_EFI_MIXED should be sufficient, however it is currently known to me that things do not end up working on fedora/ubuntu with such kernels(64-bit)/firmware(32-bit)/bootloader(32bit efi grub)
[16:35] <xnox> which is being troubleshooted, i can followup on the latest state of affairs around this internally here.
[16:53] <DHR> (sorry, was away).  xnox: that would be great, I think.  I'm not sure of what that means technically.
[16:55] <DHR> a pure 32-bit system SEEMS stupid to me, but in fact it matches these low-end systems fairly well.  They are limited in RAM by Intel (market segmentation game?  surely no good technical reason)
[16:55] <DHR> they have limited "disk" too.
[16:56] <DHR> typical right now: 2G RAM, 32G eMMC.  A flood of 1G / 16G tablets coming with Win 8.1
[16:57] <DHR> Mainstream distros seem to be sitting on the sideline.
[16:58] <DHR> I'd really love Linux to be the answer for some of those who discover how bad Win8.1 is on 1/16 tabs.  Wishful thinking?
[16:59] <DHR> I naively don't understand why a simple 32-bit-only UEFI install isn't a perfectly fine placeholder until some kind of mixed support can be engineered.
[17:02] <DHR> cjwatson: my understanding is: a pure 32-bit Ubuntu exists (obviously), but no UEFI installer for it.  I naively would have thought that creating a new .iso with a 32-bit UEFI installer ought to be just turning a crank.
[17:02] <DHR> That's why I thought that this might be an installer questsion.
[17:03] <cjwatson> I was replying specifically to your question about power management.
[17:04] <cjwatson> Adding an additional image is technically not that hard, but increases our QA load non-trivially, which is a very scarce resource.  So we're not going to do that.
[17:05] <cjwatson> We would much prefer to add the capability to one of our existing images.  The problem is that historically attempting to do this to the i386 image broke other hardware.  As I said in the meeting, it's possible that the trade-offs are different now.
[17:06] <DHR> cjwatson: thanks for the LKML link.  With interruptions, I just got to it now.  It adds a piece to the puzzle.  I wonder why it isn't working on fedora/ubuntu.
[17:06] <cjwatson> And if the hardware in question in fact has long mode (i.e. a 64-bit CPU) despite having 32-bit UEFI, then that potentially simplifies the problem considerably.  We were not clear in the meeting on whether this is in fact true.
[17:06] <cjwatson> It may be working.
[17:06] <cjwatson> I can't claim authoritatively that it doesn't.
[17:07] <DHR> the hardware I know about is advertised has being 64-bit.
[17:07] <cjwatson> In that case the next step that we arrived at in the meeting will likely work.
[17:08] <cjwatson> That is, add grub-efi-ia32 to the EFI System Partition on the amd64 images.
[17:08] <cjwatson> Although that only helps for booting the images themselves; somebody is also going to need to figure out how to detect this situation at run-time and install grub-efi-ia32 on the target system as well.
[17:08] <DHR> disk space is at a premium on these systems currently.  Isn't a mixed 32/64 system significantly fatter than a pure 32-bit system?
[17:09] <cjwatson> It wouldn't be particularly mixed.
[17:09] <cjwatson> 32-bit boot loader, 64-bit everything else.
[17:09] <DHR> As I said, 16G and 32G are the normal size.
[17:09] <cjwatson> That hardly seems likely to be problematic.
[17:10] <cjwatson> If we were talking about 4G or something then that might be more of an issue.
[17:11] <cjwatson> We appear to have CONFIG_EFI_MIXED=y now.
[17:11] <cjwatson> But I'd defer to xnox's internal knowledge.
[17:13] <cjwatson> I think infinity was going to see if somebody on the development team could expense a suitable system and make it work.
[17:13] <DHR> If that approach can work, is there a way to get a generally usable experimental image out very soon?  About detection: dunno, worst case, let the user tick a box (experimental!)
[17:13] <cjwatson> No
[17:13] <cjwatson> (to "tick a box")
[17:13] <cjwatson> I'm quite sure there's a better option than that :-)
[17:14] <cjwatson> We're not adding new UI, because, bear in mind, that would logically have to be shown to everyone installing on any UEFI system, i.e. most users, and we're not doing that to people installing vivid.
[17:14] <DHR> They are REALLY cheap.  I'd donate one if it would get things moving.  For example, $200 buys you an Asus x205.  $100 buys you one of several tablets (I can name names if that matters).
[17:15] <cjwatson> I can't speak for timelines because I'm moving out of mainline Ubuntu development at the end of the year.
[17:15] <cjwatson> Hence redirecting to infinity ...
[17:15] <DHR> Oh, but I'm an impatient user :-)  Doing it before the end of the year is important :-)
[17:17] <ogra_> send a patch then :)
[17:17] <ogra_> (or multiple)
[17:17] <cjwatson> ogra_: I don't think that's a helpful answer.
[17:18] <cjwatson> Please don't answer if that's all you're going to say.
[17:18]  * ogra_ shuts up 
[17:18] <cjwatson> Because this is too complicated for most people to know where to start ...
[17:19] <cjwatson> Information on how to detect the UEFI machine type (ia32 or x86-64) at run-time would be genuinely helpful though.
[17:19] <cjwatson> https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface says that "ioreg -l -p IODeviceTree | grep firmware-abi
[17:19] <cjwatson> " works on Mac OS
[17:19] <cjwatson> And gives a non-Mac answer which is sadly inapplicable following CONFIG_EFI_MIXED
[17:20] <DHR> cynic: every time you ask a PC about whether it conforms to some standard, it lies.
[17:20] <cjwatson> infinity: http://kernelnewbies.org/Linux_3.15#head-e6cf8178e4d5eafc23b0abda81974d2b71ffecf4
[17:21] <cjwatson> Hmm, need to fix grub2 to make linuxefi (for SB) build on i386_efi too then
[17:21] <DHR> The base line assumption: if you were installed (or perhaps booted) by a 32-bit UEFI, you are on a machine in which you should use 32-bit UEFI runtime.
[17:21] <cjwatson> DHR: I'm asking how to discover the former from userspace
[17:26] <DHR> Maybe that needs to be part of what CONFIG_EFI_MIXED adds to the mix.
[17:26] <cjwatson> There may well be information there already, but I don't know it.
[17:28] <cjwatson> But I'm suggesting that if somebody wants to help move this forward more quickly, then that's a critical-path thing we need to know that could be investigated independently.
[17:29] <DHR> OK.  Thanks for the suggestion.  What kind of interface would be good for userland?  Something in /proc or /sys?
[17:29] <cjwatson> I'd expect something in /sys
[17:30] <DHR> yeah, /proc shows how long ago I did any kernel hacking.
[17:31] <cjwatson> I think once we have that information, the steps are to make grub-installer use it, to make grub2 build linuxefi on i386 as well, to build 32-bit shim binaries (I may not like Secure Boot, but we probably need to do it here), and to add all the relevant things to our amd64 images
[17:34] <DHR> thanks for taking the time!  I'll see if I can find a hook in the patch you pointed me at.  I guess that's a bit stale now, but it's a starting point.
[17:35] <DHR> How can I best return the results (if any)?  This channel?
[17:35] <cjwatson> DHR: The kernelnewbies link above has links to the commits that actually landed, but they're probably best used as starting points for grepping current kernel source.
[17:35] <cjwatson> DHR: Probably as good as any, yes.
[17:35] <cjwatson> Thanks for looking.
[17:38] <DHR> thinking out loud: something needs to record whether the efi64_thunk needs to be used.  So the info must be represented in the kernel.
[17:39] <infinity> cjwatson: Appreciate the redirect, but on VAC until next week. :)
[17:44] <cjwatson> infinity: Oh good point.  Feel free to park it until then
[17:49] <DHR> type efi_system_table_t has a member "is64".  Seems to be  a start.