Moving to in-repo kernel & misc issues

[LekKit]

Some options in the kernel config are missing so IWD wifi manager fails to start (See below). HDMI doesn't work.

TLDR on IWD problem:

``` [root@archlinux ~]# /lib/iwd/iwd No HMAC(SHA1) support found No HMAC(MD5) support found No CMAC(AES) support found No HMAC(SHA256) support found No HMAC(SHA512) support found DES support not found AES support not found No CBC(DES3_EDE) support found, certain TLS connections might fail No CBC(AES) support found, WPS will not be available No Diffie-Hellman support found, WPS will not be available The following options are missing in the kernel: CONFIG_CRYPTO_USER_API_HASH CONFIG_CRYPTO_USER_API_SKCIPHER CONFIG_KEY_DH_OPERATIONS CONFIG_CRYPTO_ECB CONFIG_CRYPTO_MD5 CONFIG_CRYPTO_CBC CONFIG_CRYPTO_SHA256 CONFIG_CRYPTO_AES CONFIG_CRYPTO_DES CONFIG_CRYPTO_CMAC CONFIG_CRYPTO_HMAC CONFIG_CRYPTO_SHA512 CONFIG_CRYPTO_SHA1 ```

It might be wise to transition to mainline kernel from the Arch repos themselves, with all the modules, drivers and fuss - I'd expect it to work on this board, and even the official images generated by this tool (With firmware sectors slapped atop) could be supported.... Until U-Boot issues come into play:

• kernel_comp_addr_r or kernel_comp_size is not provided!
• Watchdog is enabled for some reason, which timeout on long (>15s) fallback initramfs load and we get a bootloop on first boot!
• inflate() returns -5 for whatever spectacular reason so we can't boot compressed vmlinuz kernels

I will keep this issue thread as a place to put my own and hopefully someone else' updates too on this

UPD: As it turns out, the inflate() erroring out is a symptom there is not enough room for the decompressed (30M) kernel image, which becomes obvious if we initially put it uncompressed:

Moving Image from 0x41000000 to 0x40200000, end=4210d000
ERROR: RD image overlaps OS image (OS=0x40200000..0x4210d000)

[LekKit]

As it turns out u-boot/include/configs/sunxi-common.h is pretty messed up in respect to RISC-V systems:

• Doesn't think that RISC-V systems need compressed kernels? (kernel_comp_addr_r is under #ifdef ARM64)
• Doesn't think that D1 machines have >=512M RAM so all the addresses are put in a very limited space

After patching it & disabling CONFIG_WATCHDOG U-Boot issues go away. Repo kernel immediately hangs on startup tho...

[sehraf]

I'll happily switch to Arch's kernel as soon as it's working 😃

[LekKit]

So apparently the repo kernel crashes because initrd overlaps some FDT memory region and it all goes wonky (This is after all U-Boot issues are sorted out). Likely fixable soon.

There is one remaining problem for non-nezha/mangopi boards which only have 64M of RAM in total. Basically this amount of RAM is not enough room for uncompressed kernel + initrd, let alone userspace and kernel data... Which is why I am unsure if 1 single image would cover all D1 usecases.

[sehraf]

regarding the iwd issue, can it be that you missed loading modules? (does iwd load them on its own??). Looking at the config, all listed config entries are included - mostly as modules.

[LekKit]

regarding the iwd issue, can it be that you missed loading modules? (does iwd load them on its own??). Looking at the config, all listed config entries are included - mostly as modules.

Hm, it quite possibly simply didn't load them - I wonder if that's related to lack of initrd?

Btw, here is some progress on booting the repo kernel:

• It hangs a lot later while starting init, but stops there for whatever reason

[sehraf]

I wonder if that's related to lack of initrd?

As long as you don't need iwd to mount your rootfs, there is no need to put these modules into initrd.

Btw, here is some progress on booting the repo kernel:

pinctrl failes this is probably (very) bad. You mentioned to suspect the DTB somewhere, which one are you using? AFAIR it comes from uboot? At least it is supplied by uboot when booting, i wonder how "in sync" upstream kernel and uboot are....

[LekKit]

pinctrl failes this is probably (very) bad. You mentioned to suspect the DTB somewhere, which one are you using? AFAIR it comes from uboot? At least it is supplied by uboot when booting, i wonder how "in sync" upstream kernel and uboot are....

Yea it is supplied by U-boot. I will soon try to rebuild it with a newer dtb.