-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
The answer "both".
HistoryThat 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. ImplementationsWith 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. |
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. |
Going to mark this as closed since the UEFI is probably not going to be changed. |
@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. |
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?
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)
You can actually boot without CSM everything all the way down to XP, with some little hacks.
Matt Fleming added support for mixed mode EFI in 2014 already to be fair.
Idk how that looked in 2015, but EDK2 is free and open source software.
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 |
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? |
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). |
thank you so much, i will take a look. |
Arch Linux ships with 32-bit EFI even though the OS is 64-bit, it works great for me. |
Yes, the change happened a few months after the last comments |
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.
The text was updated successfully, but these errors were encountered: