Kernel error on boot

[dmorn]

I updated this flake in my system configuration to checkout #9, next minutes I was reverting the change through UART :D The boot process stops early with

## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Using Device Tree in place at 0000000043000000, end 000000004300c221

Starting kernel ...

[    1.150061] mxsfb 30320000.lcd-controller: Cannot connect bridge: -19

The issue does not happen on revision ea814bccdcb713042f6ef4a93dcf3ebcfe2b04dd. Complete boot log attached! kernel-error.log

[jollheef]

Hello,

Have you updated U-Boot?

  nix build "github:nix-community/hardware-mnt-reform#ubootReformImx8mq"
  echo 0 > /sys/class/block/mmcblk0boot0/force_ro
  dd if=result/flash.bin of=/dev/mmcblk0boot0 bs=1024 seek=33

p.s. It was updated in 129f466daea4e66283eb96735afd83a8a311aafc

[dmorn]

Hey @jollheef thanks for joining! I did not indeed (but I also did not expect to have to). Is there a safe way to check whether the new uboot works before flashing?

[dmorn]

(I flashed it already anyway and rebuilding the configuration :'D)

[jollheef]

Is there a safe way to check whether the new uboot works before flashing?

The hardware is exactly the same, so it can be considered already tested out.

[dmorn]

...I had to recover from UART! I updated and flashed uboot to the latest version, that is working fine. I then rebuilt the system and it stopped with an error very similar to the one above. I would share the entire log but I lost it.

[dmorn]

The hardware is exactly the same, so it can be considered already tested out.

Well, generally speaking? :)

[dmorn]

Uh there is something interesting here. The working linux I'm running on right now (Linux reform 5.7.19) is reporting on startup

[    1.597522] OF: graph: no port node found in /soc@0/bus@30000000/lcd-controller@30320000
[    1.605651] mxsfb 30320000.lcd-controller: Failed to create outputs
[    1.621068] spi_imx 30830000.spi: dma setup error -19, use pio

[jollheef]

Well, this is weird. Do you use 22.05 (in flake.nix)?

[dmorn]

My flake.nix looks like

{
  description = "Configuration for MNT Reform";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    reform.url = "github:nix-community/hardware-mnt-reform";
  };

  outputs = { self, nixpkgs, reform }: {
    nixosConfigurations.reform = nixpkgs.lib.nixosSystem {
      system = "aarch64-linux";
      modules = [
        reform.nixosModule
        ./configuration.nix
        ./nvim.nix
      ];
    };
    uboot = reform.legacyPackages.aarch64-linux.ubootReformImx8mq;
  };
}

Is nixos-unstable the culprit?

[jollheef]

It may be. I use the latest stable version, so I guess it can be the source of the issue.

[dmorn]

I successfully updated the whole system to 22.05. I typed in the password blindly as mentioned in #8, now I'm not sure wether there was a problem in the boot process or I just had to type in the password blindly :') anyway, I rolled back! System performance was poor wrt the old version. I did not run any benchmark but everything feels slower. For example, I cannot reproduce videos which now I can (either through mpv or firefox). Did you notice anything similar @jollheef ?

[jollheef]

I tried now. Video is working but there is indeed some performance issues.

Now you have the latest kernel and nixos-unstable, is that correct?

[dmorn]

I will share the lock file later if needed but no, nixos 22.05 and old kernel now, the 5.17.x!

[MDr164]

Hi, so following the instructions in the README will cause the system to hang at the exact same line for me as well. Does a workaround exist currently? Running 22.05 with kernel 5.18.12 and the most recent u-boot as of writing.

[dmorn]

Hey @MDr164, are you using LUKS as well? If yes, try inputting the password blindly

[dmorn]

I'm still using the older kernel btw

[MDr164]

Yes I'm using LUKS as well. The kernel just stops after the same error you got, so far typing a password blindly didn't resume the boot. At least not via the regular keyboard.

[dmorn]

Do you have a working generation to start with at least?

[MDr164]

No, following the initial setup in the README produced a broken system. I'll have a look at restoring something working onto the eMMC the following days. I suspect dtb issues but didn't had much time to debug it.