Doug S (foo.delete@this.bar.bar) on November 15, 2020 8:55 am wrote:
> never_released (never_released.delete@this.gmx.tw) on November 14, 2020 4:12 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on November 14, 2020 1:12 pm wrote:
> > > Paul (pavel.delete@this.noa-labs.com) on November 14, 2020 3:08 am wrote:
> > > >
> > > > What do you think of the new Apple laptop?
> > >
> > > I'd absolutely love to have one, if it just ran Linux.. I have fairly fond memories
> > > of the 11" Macbook Air (I think 4,1) that I used about a decade ago (but moved away
> > > from because it took Apple too long to fix the screen - and by the time they did, I'd
> > > moved on to better laptops, and Apple had moved on to make Linux less convenient).
> > >
> > > Apple may run Linux in their cloud, but their laptops don't ;(
> > >
> > > I've been waiting for an ARM laptop that can run Linux for a long time. The new
> > > Air would be almost perfect, except for the OS. And I don't have the time to tinker
> > > with it, or the inclination to fight companies that don't want to help.
> > >
> > > Linus
> >
> > So about those... (a bit of a primer on what that hardware looks like)
> >
> > They don't run EFI but iBoot instead (but you can chainload
> > to another bootloader if you want to, not prevented
> > when Secure Boot is set to permissive). That permissive option
> > doesn't technically turn off Secure Boot. It allows
> > you to enroll your own hashes to the Secure Boot policy on the system w/ user authentication instead.
> >
> > They also do not have EL3 (which is very useful to implement PSCI inside... (only EL2,EL1
> > and EL0). There's no Arm GIC as the interrupt controller, but Apple AIC instead.
> >
> > Our strategy at checkra1n so far is, because they're modern Armv8.4 parts supporting nested virtualization,
> > reserve EL2 to ourselves. The goal is having a thin hypervisor layer to simulate a standard interrupt
> > controller, IOMMUs and PCIe ECAM-compliant controllers, which would be impossible to provide otherwise.
> > (then UEFI + ACPI will run on top, preferably with CPPC for power scaling). This approach will allow,
> > at a minor performance cost for VMs, to reduce the amount of work necessary.
> >
> > Another nice tidbit is that iBoot loads the firmware for the GPU and all the
> > other on-SoC blocks before passing through control from iBoot. This removes the
> > concerns on whether that firmware is redistributable or not in practice.
> >
> > However, reversing all of those blocks will take quite some work,
> > I hope that Apple will end up providing documentation.
> >
> > Does that plan look not too insane? (however, it'll take a while to bear its fruits)
>
>
> The problem isn't getting it to boot Linux which I doubt would be all that difficult. The
> problem is there are no public specs for their proprietary GPU, thus no driver. There may
> be some other stuff that has some driver issues like their proprietary SSD controller, but
> those are probably easier to overcome (or you can use USB4/TB3 attached storage) but the
> lack of GPU drivers means that console mode Linux is probably the best you'll ever see.
>
> I'm sure it will be pretty easy to boot Linux under Parallels, but while that would be fine for
> the average person who just wants to "run Linux" it isn't very useful for kernel development.

Hello,

The case without a FPU driver on those isn't console mode but just an unaccelerated framebuffer. Also, having the GPU firmware be loaded before we get control is very helpful when we'll try to make it work