JohnTheCoolingFan

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.