JohnTheCoolingFan

Found the issue and submitted a PR to the repository. It will take some time to get merged and then the new kernel built and put into the apt repository.

It seems that the images mostly just use some of Armbian patches, maybe some custom ones. Comparing them thoroughly and applying what I can if needed is my goal now.

First time seeing this 3.0.0 image, will check it out

@Yell BigTreeTech images are like a reference image made by bigtreetech, it doesn't have the long-terms support and usually uses old kernel versions, simply an image to use when the board was just released. The other link is a link to my forked repo where I did work on the board before it got merged into the main branch, it's a temporary branch and you should not use it. I recommend using the official Armbian image as that is what is supported on this forum, you can download it on the armbian website (armbian.com)

The patch has been added: https://github.com/armbian/build/pull/7584

I've had a person contact me on discord saying that using a orangepi 3b image with a slightly modified device tree works well, I've also mentioned that in the PR discussion. You can try that. My current goal is to translate the modifications they made onto a normal (non-flattened) device tree source and maybe include something from orangepi 3b to hopefully fix that issue, but it's a long process and I've been having some health problems recently. I want to use BTT Pi2 as a new home server, especially since the sd card in my old one died and now I am in a hiatus of trying to recover and get up and running.

The btt-cb2 branch is currently not working, hangs 170 seconds after boot, and I am working on fixing the device tree for that. BTT CB1 is a different hardware, and it's in the main branch. I handle them separately because of the different SoC families.

Sorry @Sesse but I don't know an answer to that question. You'll have to ask someone else for the reasoning behind that. I'll ask in our discord channel.

Oh crap, forgot to subscribe to the topic. Thanks @going for your work on this!

Tip for compiling: you should be able to use docker for easy cross-compilation on your pc instead of the board itself. As for thermal zones, it's probably a matter of device tree tweaking, I'll take a look.

Yeah, try the official armbian image, which includes u-boot bootloader. You can also back up the emmc data as an image, then flash the official Armbian image, try it, and then flash the backup if you want. But I think using the official Armbian image so that the appropriate u-boot is used would be best. It's fine by me to wait for the new emmc. Also, when I said remote, I meant having you try out different images and sharing the logs, not remote access over internet.

Well, the situation is that a proper ethernet driver for btt cb1 is not available and we have to use a different driver and rely on u-boot to bring the PHY up. We have been able to provide working PHY in the current branch, but not on edge. From what I remember it's a known problem and current uses a workaround I mentioned earlier. I've tested ethernet and it is working on a BigTreeTech Pi 1.2, which should be identical to a cb1 on the carrier board. From what I could find the mainboard of Sovol SV08 does seem to be similar, so I'll re-test the image. Getting ethernet to work was a very finnicky effort and it would be very bad if it doesn't work. UPD: works on my end, looks like there might be some difference in your hardware. Even if a small one. Unless the board's peripherals are the exact same as on a BigTreeTech CB1, I can't properly verify and debug the problem on my end and we will have to do that remotely.

Sorry for the silence. I haven't dealt with such an issue, will see what I can do on my board, although I have just a BTT Pi 1.2. Maybe you need to load a device driver, like i2c-gpio. I know about BTT's stance on support... Only what's needed for 3d printing and everything else goes on us.

Looks like there is a problem with the .env file. From the error message, I suspect that the file uses windows-style newlines (newlines and carriage return ("\r")), but bash expects unix-style (just newline symbol). Try changing that and trying again, it is likely the start script is executing .env as a script file and because of these errors the server itself doesn't get started. A good explanation with a number of ways to fix the problem: https://stackoverflow.com/questions/11616835/r-command-not-found-bashrc-bash-profile

Hello! If a web server is actually running, you can access it by typing "http://<YOUR PI IP>:<PORT>" in your browser. You need to know the port that the server is bound to, it is usually specified in the documentation or server startup logs. As for the Pi IP, you seem to already know it. Just make sure that the Spoolman server is running and if you have mapped the port to a different one (common when using docker) make sure to use the right port number. Pings only check access to a machine by it's IP, it doesn't use a specific port. The easiest way to check for a web server (http server) is by using a web browser, but in general you can use nmap to scan the opened and closed ports of a machine.

Sorry for the long delay. I don't have experience with CAN networks, but a quick search found this gist, which uses systemd network and udev rules to set the txqueuelen: https://gist.github.com/Lauszus/733c4c4c6abacd19a0b5dad099fab172 You can change the device name match to just can0 instead of a wildcard if you want. I've bought a few spi-to-can adapters to later test how this works myself, but if you can please try the linked method.

@townie can you please provide some logs? Maybe there's some information on why it doesn't persist. Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

I've submitted a patch to github that fixes the `light` overlay: https://github.com/armbian/build/pull/7183 It would allow to use the light overlay, if needed.

From more testing on my end, I found out that the `light` overlay causes errors. Please remove it from the list, and the CAN should work.

After changing the overlays, make sure to reboot the board. The device tree you sent shows mcp2515 as disabled. I've booted the current armbian image on my board, added just mcp2515 to the overlays, and the device tree shows mcp2515 as enabled.

Could you try the new images? They are built with new enhancements for BTT CB1, and I managed to boot with it. https://www.armbian.com/bigtreetech-cb1/

Could you try the new images? They are built with new enhancements for BTT CB1, and I have confirmed hdmi output with it. https://www.armbian.com/bigtreetech-cb1/

Thanks for your advice, this is really helpful. I am switching the board config to use bananapi sun50iw family, and it looks like most of the changes BTT made are already in the list of patches for sunxi-6.6 and sunxi-6.7 (the current config doesn't use 6.8 as edge). I'm making an analysis of the differences. The most obvious change that will be needed is to add the dts file, which is already in 6.7 but will need to be backported for 6.6. Although the device tree in the kernel makes a difference between a Pi and CB1 (SoM), which is also used on a Manta (CNC/3d-printing control board with SoM socket for CB1/CB2).

Hello. I am taking the task of organizing and performing the BTT Pi and CB1 support update. The plan is to use mainline kernel 6.6 and 6.8 (basically the default sunxi64 config) instead of the BTT fork and use patches to backport kernel patches for drivers and hardware support. The Jira issue is AR-2312, which is a collection of things that will need to be done for this initiative. @Gunjan Gupta @c0rnelius @ag123 @jernej @ALIGMSTEN I'm asking for your help on this, as Igor has said to me that you are more knowledgeable on the state of the board and what it needs. From what I've found, there has been a PR that upgraded the kernel used for BTT CB1 to 6.1.79 using patches, and there's a discussion on reconstructing or copying the BigTreeTech device tree for 6.6.y and up. The BTT's changes are mostly drivers, device tree and other hardware support and backporting. I think BTT's linux 6.2.y branch should be used as the starting point to determine what board-specific patches and changes are needed. Some of the drivers are already in the 6.6.y (CURRENT) and 6.8.y (EDGE) kernel versions, some are added by armbian, some are only in the vendor's fork.

Both of these problems got resolved today... And I'm a bit ashamed to tell how they were resolved, but I should document this: WiFi starts working after a reboot, confirmed on the btt-cb2-rebase branch. The board name is correct (the one in /etc/armbian-release and in motd) if debs and packages-hashed dirs in the output dir are cleaned (rm -r).