Skip to content
This repository was archived by the owner on Mar 23, 2025. It is now read-only.

Conversation

adminy
Copy link
Contributor

@adminy adminy commented Jun 18, 2024

things tested and working:

  • boots on pi 5 b
  • libcamera works
  • nixpkgs master works

things to try out:

  • [ ] uboot booting, see if its fixed. Uboot still not working
    • test sd card boot

IMG_6753

  • pi 4 test.

This should fix #19
Untested but maybe also #16

Serial error

DRAM:  1016 MiB (effective 8 GiB)
RPI 5 Model B (0xd04170)
Core:  22 devices, 11 uclasses, devicetree: board
MMC:   mmc@fff000: 0, mmc@1100000: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... 
In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
mbox: Header response code invalid
bcm2835: Could not query MAC address
Net:   No ethernet found.

starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
No EFI system partition
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
** Booting bootflow '<NULL>' with efi_mgr
Loading Boot0000 'mmc 0' failed
EFI boot manager: Cannot load any image
Boot failed (err=-14)
** Booting bootflow 'mmc@fff000.bootdev.part_2' with extlinux
------------------------------------------------------------
1:      NixOS - Default
Enter choice: 1 
1:      NixOS - Default
Retrieving file: /boot/extlinux/../nixos/4ljfp9dpyfv3r0pw1b8nwwxysc2c59fx-linux-rpi-6.6.34-Image
Retrieving file: /boot/extlinux/../nixos/iphdbw2np9dsacx7i37xbazqkczjsiaz-initrd-linux-rpi-6.6.34-initrd
append: init=/nix/store/4cpd34134wcaxqy4hj0dchkq020ccnb3-nixos-system-box_8-24.11/init console=serial0,115200n8 console=tty1 loglevel=7
Moving Image from 0x80000 to 0x200000, end=27a0000
ERROR: RD image overlaps OS image (OS=200000..27a0000)
Boot failed (err=-14)
No working controllers found
No ethernet found.
No ethernet found.
U-Boot> 

@SebTM
Copy link
Contributor

SebTM commented Jun 22, 2024

Thanks for the fast update (and providing binary-cache to test) - the changes itself look good to me but I encountered issues compared to building against master. When booting the pi networking is somehow broken - I haven't debugged further - just took that photo when plugging a monitor for now:

photo_2024-06-22_20-32-40

Normally the pi is configured to join by wifi after boot which works when building against master with 24.05 ✌🏻

@adminy
Copy link
Contributor Author

adminy commented Jun 22, 2024

I noticed some wifi issues also. could be that the latest wifi firmware is unstable. I switched to 5ghz and the issue still persists but I see no warnings. something's not right with the firmware.

@SebTM
Copy link
Contributor

SebTM commented Jun 22, 2024

I see, I would suggest (not a maintainer of the project) to maybe split up the PR with the "safe" / "stable" and the wireless update in separate then maybe?

Copy link
Contributor

@tstat tstat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR! I put this stuff on github in the first place because I want to collaborate on this work with others, so I welcome this PR.

That being said, I think there are a number of uncontroversial changes in here, but they are mixed in with other unrelated changes that require more discussion.

It would be easier to consider PRs that have a more narrow focus. So, I would recommend closing this PR and opening a number of PRs, each with a specific focus (e.g. dependency bumps, adding defconfig to kernel, etc).

Comment on lines 55 to 57
kernelPatches = [];
defconfig = "${board}_defconfig";
postFixup = "";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding these options sounds good to me. However, most of the other changes to this file conflict with its current design I think.

For example, master supports having multiple kernel versions under pkgs.rpi-kernels, as each key in this attrset is a kernel version, and the helper pkgs.rpi-kernels.latest exists to point to the latest. The rpi-kernel binding in this let is to help build any kernel version. The changes in this branch specialize it to the provided version, replace <VERSION> with latest_<BOARD>, and drop the latest setting. None of that seems like an improvement to me.

It would probably make more sense to replace pkgs.rpi-kernels.<VERSION>.kernel with an attrset that provides the kernels as configured per board. For example: pkgs.rpi-kernels.<VERSION>.kernels.<BOARD>.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also maybe untangle the boot loader and wireless firmware from it. Because I don't think those are board or kernel dependent. I'll see what I can do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated this to pkgs.rpi-kernels.<VERSION>.<BOARD>, and untangled it from the firmware. What do you think of the new code @tstat ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on mobile right now, but it looks great! I'll give it a closer look when I'm at a computer later.

, ninja
}:

{ libcamera-apps-src, lib, pkgs, stdenv }:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why diverge from the well-established callPackage pattern and instead pass in pkgs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, those are coming from pkgs, Its mentally easier to wrap your head around the fact that callPackage just provides pkgs rather than it also does a spread, which confuses me, because we're not passing all these extra params.

Comment on lines 27 to 49
buildInputs = old.buildInputs ++ (with final; [
libpisp openssl libtiff
(python3.withPackages (ps: with ps; [
python3-gnutls pybind11 pyyaml ply
]))
libglibutil gst_all_1.gst-plugins-base

]);
patches = [ ];
mesonFlags = [
"--buildtype=release"
"-Dpipelines=rpi/vc4,rpi/pisp"
"-Dipas=rpi/vc4,rpi/pisp"
"-Dv4l2=true"
"-Dgstreamer=enabled"
"-Dtest=false"
"-Dlc-compliance=disabled"
"-Dcam=disabled"
"-Dqcam=disabled"
"-Ddocumentation=enabled"
"-Dpycamera=enabled"
];

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you describe/motivate these changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libcamera version 2 now requires these flags to build. it was in their readme.

rpi/default.nix Outdated
Comment on lines 318 to 319
# Some patches cannot be applied because they are already upstream.
ignoreConfigErrors = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you motivate this?

Copy link
Contributor Author

@adminy adminy Jun 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest kernel has patches that could not be overwritten, so rather than not using nixpkgs rpi-kernels nix configuration, I just said, ignore failed patch applies. If you have another suggestion, please let me know.

@tstat
Copy link
Contributor

tstat commented Jun 24, 2024

I went to build an image with this branch yesterday, but there were some syntax errors in the kernel derivation. I pushed some fixes and will test an image later today.

@adminy
Copy link
Contributor Author

adminy commented Jun 24, 2024

So a silly mistake happened. My lock file locked a version of the local copy I had, I thought I was making testable changes but it was just running an older version of the flake :D Thanks for your changes, much appreciated!

@adminy
Copy link
Contributor Author

adminy commented Jun 24, 2024

I have tested it with 6.6.34 and it works fine, with the exception of the wifi, there seems to be an issue with it being terribly slow/choppy (but no patches required). Compiling the 6.6.31 also went smoothly! No more ignore errors!
Also on 6.6.31 the wifi has no issues! So good that its left as default.

@adminy
Copy link
Contributor Author

adminy commented Jun 28, 2024

Screenshot 2024-06-28 at 07 57 27 Tested again, fixed wifi issues in the latest rc pi linux it seems.

@tstat tstat merged commit c92bd86 into nix-community:master Jul 8, 2024
@tstat
Copy link
Contributor

tstat commented Jul 8, 2024

Thanks for the contribution!

@adminy adminy deleted the upgrade-with-fixes branch July 8, 2024 21:30
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[24.05] Build
3 participants