Mainline Kernel building -- problems and issues

[pihacker]

Hello. I try to get the mainline linux kernel working on my RPi4. The main guide I use is this tutorial -- https://gist.github.com/lategoodbye/c73 ... aed8c68f75
I tried to compile both 32-bit version (with multi_v7_defconfig) and 64-bit (with defconfig). I managed to boot with 32-bit version kernel -- USB and wifi works, but not ethernet and GPIO. RGMII PHY modes may be somehow related to the Ethernet problem (https://github.com/lategoodbye/rpi-zero ... -610887943). I tried to change that property in bcm2711-rpi-4-b.dts from "rgmii-rxid" to "rgmii" but that didn't help

64-bit kernel doesn't boot at all -- I get black screen (no rainbow) and two fast short green led blinks on the board. Default defconfig is not sufficient? It is interesting that Arch-aarch64-latest kernel boots well, it seems that they use a slightly different .config, but how can I found how they differ?
UPD I've managed to boot with 64-bit kernel, builded with arch-aarm64 config (https://archlinuxarm.org/packages/aarch ... les/config) It's inetesting that it took much time to build kernel with that config, but this works! I don't know why defconfig is not sufficient to make working kernel.

[pihacker]

@pihacker You never mentioned the kernel version or the base of your kernel config you are using.

Did you overwrite the bcm2711-rpi-4-b.dtb on your sd card with the mainline version?
For ethernet you should use multi_v7_defconfig and make sure CONFIG_BROADCOM_PHY=y
For USB you also need to enable CONFIG_ARM_LPAE and CONFIG_PCIE_BRCMSTB.
In order to get a serial console, please replace serial0 with ttyS1 in the cmdline.txt.

Edit: For experiments with the mainline kernel, i strongly recommend to use Raspbian / Raspberry Pi OS as rootfs.

-- I always use the latest kernel when experimenting with kernel building, so it is v5.7 at this moment.
-- Yes, I overwrited bcm2711-rpi-4-b.dtb
-- I also enabled CONFIG_BROADCOM_PHY CONFIG_ARM_LPAE (missing in 64-bit) and CONFIG_PCIE_BRCMSTB

[PhilE]

You don't need LPAE (Large Physical Address Extension) in 64-bit kernels because physical addresses are already 64 bits.

[pihacker]

@PhilE thanks. What could two short blinks mean? According to this article - https://elinux.org/R-Pi_Troubleshooting ... ic_pattern that means SD card cannot be read, but I'm sure this is not the problem, because when I place old kernel back, RPi boots well again.

[pihacker]

I've managed to boot with 64-bit kernel, builded with arch-aarm64 config (https://archlinuxarm.org/packages/aarch ... les/config) It's inetesting that it took much time to build kernel with that config, but this works! I don't know why defconfig is not sufficient to make working kernel.

[jamesh]

@PhilE thanks. What could two short blinks mean? According to this article - https://elinux.org/R-Pi_Troubleshooting ... ic_pattern that means SD card cannot be read, but I'm sure this is not the problem, because when I place old kernel back, RPi boots well again.

https://www.raspberrypi.org/documentati ... arnings.md

[swahren]

This whole problem description is hard to follow. I think we should concentrate on one issue.

What is your goal 32 or 64 bit?
What rootfs are you using?
What are the relevant config.txt settings?

Btw it was proven that PHY mode was a red herring, so no need to touch this.

[pihacker]

@swahren I'm sorry that thread quickly became so broad and hard to follow. Let me explain my goals. The main goal is to get mainline kernel as much working and usable as possible. As 32-bit seems to be more "old" and "deprecated", I would prefer to stick with 64-bit kernel. I only tried to compile and use 32-bit kernel just to make sure that it is even possible to boot with mainline kernel at all, but since I convinced that it is possible to compile and use 64-bit kernel, I stuck to it.
I'm not sure what do you mean when you say "rootfs". I use ARM Arch Linux as build environment and corresponding initramfs since it is proven to be working. I also use arch's .config since make defconfig gives me config which than produces unusable 64-bit kernel and I don't know what is the issue with that.
I try to keep config.txt and cmdline.txt as plain and small as possible, so as for now it is only 4 LOC:

Code: Select all

gpu_mem=64
kernel=Image
arm_64bit=1
initramfs initramfs-linux.img followkernel

cmdline.txt

Code: Select all

root=UUID=fbc84acc-9f96-4920-91f1-efcfd51c05cb rw rootwait console=serial0,115200 console=tty1  plymouth.enable=0

Ethernet is working now with default PHY mode.
What is not working is serial console and I guess that GPIO doesn't work at all. I think that some kernel config parametes are wrong or missing but I don't have any clue what exactly.
So I think my primary point of interest now is making serial working.
JFYI -- my current kernel config is just https://archlinuxarm.org/packages/aarch ... les/config

[swahren]

I must confess that i usually try to avoid initramfs. For 64 bit i only used Raspberry Pi OS 64 bit so far. But i wouldn't consider 32 bit as deprecated.

As i suggested on the other thread, try to replace "serial0" with "ttyS1" in the cmdline.txt. This should make serial work.

How did you come to the conclusion GPIO doesn't work? Please keep in mind the GPIO sysfs interface is deprecated and do not start with 0 (in mainline).

[pihacker]

@swahren What should I use instead of initramfs? I'm a total newbie and I thought initramfs is essential to the boot process.
I tried your suggestion from previous post, but I didn't understand you correctly. I tried console=ttyS0 and that gave me nothing, but console=ttyS0,115200 gave me something strange:

I suggested that GPIO doesn't work because serial doesn't, because serial works through GPIO, isn't it?

[swahren]

You can try console=ttyS1,115200 . In case you see the strange output, this comes from changing core frequency. I think enable_uart=1 could help here. Btw the ttyAMA0 is already reserved for Bluetooth.

Instead of initramfs, you can store all the kernel modules in the root partition. Just like Raspbian / Raspberry Pi OS does. But you need to remove the 4th line in your config.txt.

[pihacker]

Neither ttyS0 nor ttyS1 works for me, no matter do I use enable_uart or don't.
I also found out that defconfig rathrer produce kernel without proper HDMI support than just unbootable kernel, that's why I got black screen, instead of rainbow. What config property defconfig misses to enable HDMI?

[swahren]

VC4 KMS support isn't mainlined yet. The whole RPi 4 support is still in progress.

[pihacker]

@swahren yet HDMI works being compiled with arch's config. What am I missing?

[swahren]

Yes, it's using simple framebuffer as a workaround. Sorry, i don't have the time for deep investigations but try to apply similiar config options from ARCH config like this:

CONFIG_FB_SIMPLE=y

[pihacker]

@swahren thank you, any help is very appreciated.

[pihacker]

@swahren, yeah, that was CONFIG_FB_SIMPLE, HDMI works now!
garbage in a serial console is the problem now.

[swahren]

garbage in a serial console is the problem now.

There isn't much we can do from kernel side. The parent of the mini UART clock is under control of the VideoCore firmware.

I see two options: remove bluetooth from the other UART and use this instead or force the Core to use a fixed clock.

[pihacker]

@swahren my current config.txt contains following lines:

Code: Select all

# gpu_mem=64
kernel=Image
core_freq=250
enable_uart=1
arm_64bit=1

So I think core freq should be fixed, but I still get garbage from serial console
Also, as I understand, bluetooth disabling allows to use Full UART instead of miniUART. It's interesting that I don't see any /dev/ttyAMA* devices. Anyway, I tried to blacklist bluetooth kernel module with no success. Does overlays like disable-bt work with upstream kernel?

[PhilE]

The minimum core frequency on a Pi 4 is 200MHz - you need to set core_freq and core_freq_min to the same value to ensure it doesn't change.

[pihacker]

@PhilE
https://www.raspberrypi.org/documentati ... locking.md

Changing core_freq in config.txt is not supported on the Pi 4, any change from the default will almost certainly cause a failure to boot.

But I'm still able to boot... Also table in the doc gives me 250/275 (why different?) for core_freq_min defaults.

[rimrunner]

I tried to use the tutorial of the first post on this thread for building a 32-bit linux-next for RPi4 but without cross-compiling (so I partly used the standard instructions to get through without any cross-compiling).

I didn't have success, it gets stuck on the initial color screen.

I'm trying to find out what went wrong.

The tutorial doesn't mention anything about *.dtbo -files (overlays). What about them?

And when compiling linux-next, it seems there are no overlay directory in the resulting kernel tree.

Should I compile those dts files that I can found from arch/arm/boot/dts by myself as well and use them as overlays..?

Anything else that could have caused the failure?

[swahren]

These overlays are not supported by the mainline kernel.

[rimrunner]

These overlays are not supported by the mainline kernel.

So, no overlays are needed at all to get Raspbian running?

[swahren]

These overlays are not supported by the mainline kernel.

So, no overlays are needed at all to get Raspbian running?

Yes, they are only necessary for I2C or SPI busses. Also mainline DTS are compiled differently which isn't compatible to overlays.