GithubHelp home page GithubHelp logo

nixos-sbc's Issues

Loading Environment from MMC... mmc fail to send stop cmd

This is weird.

I migrated my flake to your nixos-sbc. I had some problems with disko which I disabled.
In the end I was able to produce an image that seemed to be running fine. I had UART attached and everything booted. I attached eth cable and was able to ssh into the router. I restarted it and it booted again.

Not sure if this is the case for every bpir3 devices but mine doesn't have wifi when UART is connected (can be also an issue with this particular UART device). Anyway this is a known issue, and maybe not relevant.

I detached UART and rebooted router so that it will boot this time with wifi.

Unfortunately, it did not boot. I did not have UART attached so I don't know what exactly happened. I attached UART and the logs show following:

NOTICE:  BL2: v2.7(release):

NOTICE:  BL2: Built : 00:00:00, Jan  1 1980

NOTICE:  WDT: disabled

NOTICE:  CPU: MT7986 (2002MHz)

NOTICE:  EMI: Using DDR4 settings

NOTICE:  EMI: Detected DRAM size: 2048MB

NOTICE:  EMI: complex R/W mem test passed

NOTICE:  BL2: Booting BL31

NOTICE:  BL31: v2.7(release):

NOTICE:  BL31: Built : 00:00:00, Jan  1 1980





U-Boot 2024.01 (Jan 08 2024 - 15:37:48 +0000)



CPU:   MediaTek MT7986

Model: BananaPi BPi-R3

DRAM:  2 GiB

Core:  37 devices, 14 uclasses, devicetree: separate

MMC:   mmc@11230000: 0

Loading Environment from MMC... mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

*** Warning - bad CRC, using default environment



Loading Environment from nowhere... OK

In:    serial@11002000

Out:   serial@11002000

Err:   serial@11002000

Net:   eth0: ethernet@15100000

Hit any key to stop autoboot:  0

Scanning for bootflows in all bootdevs

Seq  Method       State   Uclass    Part  Name                      Filename

---  -----------  ------  --------  ----  ------------------------  ----------------

Scanning bootdev '[email protected]':

mmc fail to send stop cmd

mmc fail to send stop cmd

 ** fs_devread read error - block

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

mmc fail to send stop cmd

No more bootdevs

---  -----------  ------  --------  ----  ------------------------  ----------------

(0 bootflows, 0 valid)

BPI-R3>

This exact sequence happened already twice so it is not a total coincidence.
After it happens the image is no longer bootable and I have to flash the sd-card again.

repo link

Announcements and updates

Subscribe to this issue to get notifications about releases, breaking changes, or any other noteworthy comments.

sbcLibPath causing infinite recursion when used out-of-tree

sbcLibPath is causing infinite recursion when used outside of this repository.

          hostA = nixosSystem {¬
            system = "aarch64-linux";¬
            modules = [¬
              nixos-sbc.nixosModules.default¬
              nixos-sbc.nixosModules.boards.bananapi.bpir3¬
              ({config, sbcLibPath, ...}: {
                imports = [
                  (import (sbcLibPath + "/devices/rtc/ds3231/create.nix") {
                     i2cConfig = config.sbc.board.i2c.devices.i2c0;
                   })
                ];
              })
            ];¬
          };¬
```

SinoVoip BananaPi R4 Support

The BPiR4 has had initial support added, however it is not yet ready for prime-time use.

  • Persistent hardware-unique ethernet MAC Addresses
  • Persistent hardware-unique WiFi MAC Addresses for WiFi7 iPA NIC Module
  • Consistent reliable boots
  • Reliable first-boot partitioning
  • WiFi assert on AcceptRegulatoryResposibility if hardware requires user to put consideration into setting it up
  • RTC driver for AT8563

bpi-r3: frequent wifi drops (probably due to VLAN)

i've been using the bpi-r3 with VLAN enabled for a while and have been seeing the AP disappear for several seconds alongside the following message:

Aug 04 11:22:02 router0-dmz0 kernel: mt798x-wmac 18000000.wifi: Message 000026ed (seq 14) timeout

relevant links:

as mentioned in one of the issues, a firmware update has been provided that probably fixes this: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=5d0d24b3b4207292dd2b1e927348899e10e06427

i'm not sure how to best apply this "feed" to the mtk repo that we use here. any ideas for this?

for now i'm using the workaround/patch described here which has been alleviating the problem for me. however i understand it's not a general solution long-term and might point to an underlying firmware issue.

CI and Caching

This issue is tracking the progress of CI and Caching

  • Update flake.lock when changes in nixpkgs impacts our derivations 08f44ab
  • Build and push to cachix
    • On flake update 08f44ab
    • On local derivation update TODO
  • Move to main being unbuilt and a different branch being updated after cache updates.
  • Add cache as a nixos-sbc module.
    • Do not surprise people with binaries:
    • Opt-in if sbc.version == "0.2"
    • Opt-out if sbc.version >= "0.3"

TODO: Flush this issue out

u-boot bootflow btrfs tracking issue

BTRFS seems to fail to read if a number of bytes to read is provided.

=> load mmc 1:3 ${pxefile_addr_r} /boot/extlinux/extlinux.conf
658 bytes read in 45 ms (13.7 KiB/s)

=> load mmc 1:3 ${pxefile_addr_r} /boot/extlinux/extlinux.conf 658
** /boot/extlinux/extlinux.conf shorter than offset + len **
0 bytes read in 28 ms (0 Bytes/s)

Bootflow responds:

Scanning bootdev '[email protected]':
trying: /boot/extlinux/extlinux.conf
   /boot/extlinux/extlinux.conf - err=0
   - script file size 292
** /boot/extlinux/extlinux.conf shorter than offset + len **

Solving this should get BTRFS booting with bootflow.

bpir3 pcieFixup doesn't seem to work

The pcieFixup is turned on by default.

The implementation of the workaround is the same as it used to be with older kernels. However, it seems that it doesn't work anymore. When I try to configure nvme device I am getting:

<<< NixOS Stage 1 >>>



loading module rfkill...

loading module cfg80211...

loading module mt7915e...

loading module mii...

running udev...

Starting systemd-udevd version 255.6

kbd_mode: KDSKBMODE: Inappropriate ioctl for device

Gstarting device mapper and LVM...

checking /dev/disk/by-uuid/0b5e3376-c7e9-4284-9514-9c3b51244f19...

fsck (busybox 1.36.1)

[fsck.ext4 (1) -- /mnt-root/] fsck.ext4 -a /dev/disk/by-uuid/0b5e3376-c7e9-4284-9514-9c3b51244f19

root: recovering journal

root: clean, 278458/7449072 files, 1519866/30558075 blocks

mounting /dev/disk/by-uuid/0b5e3376-c7e9-4284-9514-9c3b51244f19 on /...

waiting for device /dev/disk/by-partlabel/disk-nvme0n1-var to appear.......................

Timed out waiting for device /dev/disk/by-partlabel/disk-nvme0n1-var, trying to mount anyway.

mounting /dev/disk/by-partlabel/disk-nvme0n1-var on /var...

[   36.127976] /dev/disk/by-partlabel/disk-nvme0n1-var: Can't lookup blockdev

mount: mounting /dev/disk/by-partlabel/disk-nvme0n1-var on /mnt-root/var failed: No such file or directory



An error occurred in stage 1 of the boot process, which must mount the

root filesystem on `/mnt-root' and then start stage 2.  Press one

of the following keys:



  r) to reboot immediately

  *) to ignore the error and continue

Ignoring the error actually correctly boots the system with the nvme partitions mounted. The problem is that the boot process halts until user makes the choice.

Break out "ramify" the on-boot storage manipulation scripting

I've called the on-boot subvolume manipulation "ramify".

This could be useful outside SBC environments, so this issue tracks my plan to pull it into its own repo, or at the least its own module.

Additionally, by being a stand-alone module, it should be easier to see it exists and audit what it does, which is good seeing as it does file manipulation on boot.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.