Asus C101PA no longer boots

[divVerent]

Since upgrade to linux-aarch64-5.8.0-1-aarch64.pkg.tar.xz + linux-aarch64-chromebook-5.8.0-1-aarch64.pkg.tar.xz, my Asus C101PA Chromebook no longer starts when I press Ctrl+U on the boot screen to boot from SD card. It just beeps, shows black screen for a third of a second, and returns to the developer mode boot screen - no messages whatsoever about what is wrong. Is there any way to get some information about what failed?

Booting into ChromeOS (Ctrl-D) works, and from there I managed to downgrade to 5.7.8-1 from my /var/cache/pacman/pkg, which boots fine.

Any idea why, and what changed? I see only changes to the kernel config in the PKGBUILD, which seem to be the typical "make oldconfig" stuff. A very obvious change though is that the old kernel package has a .kpart file of 29.3 MiB and the new one is much larger (35.7 MiB). My kernel partition is 128 MiB though (resized from 32 MiB after the -rc kernel broke the 32 MiB barrier before, but that one still booted fine). So could it be that there is a limitation to kernel size on this device and it's been broken of course just a guess, as I see no error message at all, just the beep? If so, any plans for a workaround that is "more convenient" than me compiling my own kernel with a trimmed down config on every update?

FYI, the current linux-aarch64-chromebook-rc fails for me the same way, too.

[divVerent]

Looking at vboot, depthcharge sources, I found that there indeed is a parameter called kernel_buffer_size that's static (sometimes seems to come from a macro CHROMEOS_KERNEL_BUFSIZE or CONFIG_KERNEL_SIZE). However I couldn't find the sources that apply to this Chromebook (bob) yet, and the common sizes for this I could find online were 8 MiB and 80 MiB.

Looks like until 2018, CONFIG_KERNEL_SIZE was 32 MiB indeed: https://github.com/coreboot/depthcharge ... d92310d211 (see src/image/Kconfig). So this issue likely applies to most Chromebooks until 2018.

That probably explains my problem; but if that's the case, we probably will require a kernel < 32 MiB. My vmlinux.kpart of the last working kernel is only 11.6 MiB when gzipped - can that somehow be utilized? Like, putting a small loader in front of the kernel that uncompressed the kernel to elsewhere and then boots it from there? I know this isn't trivial to do on a device like that, but didn't we do that on x86 for ages? Maybe we're lucky and it's just a CONFIG_ option to the kernel image? Probably not, as apparently there's no decompressor in the arm64 Linux kernel, but I did find some stub hackery here: https://github.com/aswild/rpi3-decompress-stub - but I understand this probably doesn't just apply as is.

Till then, may I suggest rolling back the AL ARM repo to the last known working kernel?

[divVerent]

Confirmed: it's indeed just the kernel size.

With this patch applied:

https://gist.github.com/divVerent/1e5b6 ... 453650f3dd

which merely disables all non-Rockchip architectures, I got the kernel down to 30 MiB and it boots fine.

Clearly I can't seriously ask for this patch to be applied as it'd probably break lots of other ARMv8 Chromebooks. But given I changed nothing other than removing code that's clearly dead on my system, this confirms that it's indeed just a size problem.

So, how can we proceed here? I can of course always submit a fork of the kernel package to AUR, and would then have to update it myself whenever the upstream package changes (luckily my changes are intended to not need much maintenance - thus the use of olddefconfig so I can keep using the ALARM .config and only a minor patch on top, rather than including all options depending on the architectures I disabled in the same patch). But much better would be a real fix.

Now I don't know the Chromebook landscape well enough, but I bet we are including lots of stuff no Chromebook ships with, so I guess those would be the first candidates to actually disable.

During the kernel build I also noticed some obviously useless stuff (e.g. the nouveau and amdgpu drivers), but that's only compiled to a module and thus isn't my problem here. Only wastes compile time and a little disk space.

[divVerent]

A more stable way than patching .config would be this edit to the PKGBUILD:

```
+ # We only need ROCKCHIP arch.
+ scripts/config --disable ARCH_BCM2835
+ scripts/config --disable ARCH_HISI
+ scripts/config --disable ARCH_MEDIATEK
+ scripts/config --disable ARCH_MESON
+ scripts/config --disable ARCH_MVEBU
+ scripts/config --disable ARCH_MXC
+ scripts/config --disable ARCH_QCOM
+ scripts/config --disable ARCH_SEATTLE
+ scripts/config --disable ARCH_SUNXI
+ scripts/config --disable ARCH_TEGRA
+ scripts/config --disable ARCH_VEXPRESS
+ scripts/config --disable ARCH_XGENE
+
+ # Disable file system we do not use.
+ scripts/config --module F2FS_FS
+ scripts/config --module FAT_FS
+ scripts/config --module MSDOS_FS
+ scripts/config --module NFS_FS
+ scripts/config --module VFAT_FS
+ scripts/config --module XFS_FS
+
+ # That's no fun on ARM anyway.
+ scripts/config --disable VIRTUALIZATION
+
+ # Disable obviously useless modules. They take ages to compile.
+ scripts/config --disable DRM_AMDGPU
+ scripts/config --disable DRM_NOVEAU
+ scripts/config --disable DRM_RADEON
+
+ # Minimize kernel size.
+ scripts/config --disable CC_OPTIMIZE_FOR_PERFORMANCE
+ scripts/config --enable CC_OPTIMIZE_FOR_SIZE
+
+ # Make everything consistent again.
+ make olddefconfig
```

My kernel is down to 22 MiB now, having lots of headroom to boot.

Note: I picked the exclusions based on checking size of kernel object files; NFS and XFS took a lot of space, as well as the extra archs and KVM (which, to be honest, is usually rather boring except on x86).

The graphics drivers are normally just modules, but they take long to compile which is why I took them out too.