Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

32/64 bits #4

Closed
z3t0 opened this issue Aug 26, 2015 · 10 comments
Closed

32/64 bits #4

z3t0 opened this issue Aug 26, 2015 · 10 comments

Comments

@z3t0
Copy link

z3t0 commented Aug 26, 2015

Hi,

I am waiting for my tablet to arrive and plan on contributing heavily to this project. First of all I would like to ask some questions so I can better understand the situation (will create separate issues for each topic) . First of all, does the tablet itself not support 64 bits? or is it that we can only install windows 32 bit? Was a 32bit bios installed on the tablet?

EDIT: Until I have something solid all my findings will be posted here, https://gist.github.com/z3t0/8e4227732dda6edbdc6e

Please do not share the information there anywhere else, just share the link. That way any false information is not shared as I will update things frequently.

@Manouchehri
Copy link
Owner

The answer "both".

  • CPU supports IA-32 and Intel 64
  • Insyde UEFI is IA-32 only

History

That hardware setup isn't logical and not continued in the future. It was a business/time management issue, not a technical decision.

This happened because Microsoft's InstantGo team (Instant Connect at the time) was having last minute issues on Intel 64 when shipping Windows 8.1; at the same time, Microsoft had also decided that in order for a device to be Windows certificated, it had to have InstantGo support. Ultimately, it forced manufacturers to use a IA-32 UEFI until the issues were resolved toward the end of Q4 2013.

During Q3 2013, Intel's Atom Bay Trail line was put into production. Since most of the software and schematics were probably drawn up in Q1, the decision to use Insyde's IA-32 platform definitely made sense. In hindsight it probably still would have been done like that just due to time constraints.

Now, Insyde actually does have a 64-bit option for Android listed on it's website, although it's not clear if they ever made one for InsydeH20. I'm going to poke around a bit more online and see if I can find anything interesting.

Usually once a device ships, all the engineers will move onto a new project. It's difficult to continue funding a product that's no longer for sale. Even if InsydeH20 does have a Intel 64 build for Bay Trail ready to go, it's unlikely that there's any developers remaining at the OEM to release it. There's a lot of debate right now about the lack of post-sale support for even critical security patches in consumer devices. If you replace the word "Android" with Insyde/Phoenix/AMI, it's the same story. Google's Chromium team is fixing the closed UEFI situation with coreboot + U-Boot setup and it seems to be working; no mainstream support outside of them though.

Implementations

With the history given above, we're stuck with InsydeH20 IA-32 and no legacy BIOS.

Microsoft doesn't have a lot of great explanations of how their boot loader works, and it's sort of a moot point as well; it's closed source anyway, no external changes can be made easily. They've made the (fair) assumption that you will run the same UEFI architecture as your CPU. With just IA-32 UEFI, the choices are Windows x32 8, 8.1, 10 and possibly 7.

GRUB2 is a little bit different. It doesn't care what architecture you boot to, as long as both the EFI and CPU have supported. However, you can't chainload different EFI architectures together (otherwise, you would be able to chainload Microsoft's 64-bit UEFI to GRUB2's x86 EFI1). Somebody else would be better at explaining why that works, I haven't had any practical assembly or architecture design experience.

As far as mainstream Linux distributions, only Debian has put in effort to make architecture mixing work out of the box. Actually, it seems to have been mostly pushed forward by one person (Steve McIntyre). You can opt to compile GRUB2 yourself (which is what I did initially) and run it on whichever distribution you'd like. That being said, you're likely to be the maintainer of it, so it's difficult to find support if issues arise. I kept running into kernel panics on Arch Linux and didn't feel it was worth it to spend time on debugging that when there's other tasks that could be focused on.

I'll maintain a list of currently support operating systems on the front page (README.md). This post was a bit too long for an overview, which is why I'm not going to duplicate it there.

1 UEFI is an implementation of EFI, and requires membership (free). I may be wrong, but I'm going to guess the GNU Project doesn't like the UEFI Forum. They pretty much don't support anything that doesn't license their software under the GPL.

@Manouchehri
Copy link
Owner

I see you're working on testing out the wireless driver, if you could post your results (or link) in #2 that would be great! If not I'm sure I'll check your Gist sooner or later.

@Manouchehri
Copy link
Owner

Going to mark this as closed since the UEFI is probably not going to be changed.

@z3t0
Copy link
Author

z3t0 commented Aug 27, 2015

@Manouchehri I do plan on testing the wireless driver, but keep in mind that it is likely to be atleast a week (likely 1.5 - 2wks) until I receive my device.

@mirh
Copy link

mirh commented Sep 3, 2020

I'm going to poke around a bit more online and see if I can find anything interesting.

A 32-bit OS and applications get you something between 15% and 20% less RAM usage than the same exact thing in 64-bit mode?
And when you have just 2GB of ram it can make all the difference in the world between "happily browsing the web with a bunch of tabs open while spotify plays music" and "having to swap out memory".

If you replace the word "Android" with Insyde/Phoenix/AMI, it's the same story.

Firmware has not the same attack surface of an operating system (which has already funnily enough demonstrated to be secure-ish enough, despite those apocalyptic takes)

and possibly 7.

You can actually boot without CSM everything all the way down to XP, with some little hacks.

Actually, it seems to have been mostly pushed forward by one person (Steve McIntyre).

Matt Fleming added support for mixed mode EFI in 2014 already to be fair.

UEFI is an implementation of EFI, and requires membership (free).

Idk how that looked in 2015, but EDK2 is free and open source software.
Also, I'm pretty sure the specifications have always been public.

They pretty much don't support anything that doesn't license their software under the GPL.

GPLv3 has nothing to do with anything linux-related.

p.s. fwiw Hans de Goede kept pushing forward support for bay trail during these years

@legop3
Copy link

legop3 commented Jan 8, 2022

I know it's been a while, but I assume this means it is impossible to boot anything 64 bit on tablets with this limitation, am I correct?

@mirh
Copy link

mirh commented Jan 8, 2022

No you aren't. 64-bit linux on 32-bit UEFI is a pretty well known thing (even though it may require some hacking, as also evidenced by this repository instructions).
https://medium.com/@realzedgoat/a-sorta-beginners-guide-to-installing-ubuntu-linux-on-32-bit-uefi-machines-d39b1d1961ec
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI
It's only windows on the other hand that is a mystery.

@legop3
Copy link

legop3 commented Jan 8, 2022

thank you so much, i will take a look.

@tomek-szczesny
Copy link

Arch Linux ships with 32-bit EFI even though the OS is 64-bit, it works great for me.

@mirh
Copy link

mirh commented Aug 21, 2024

Yes, the change happened a few months after the last comments
https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/216

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants