Jump to content

JohnTheCoolingFan

Members
  • Posts

    29
  • Joined

  • Last visited

Other groups

Contributor/Maintainer

Profile Information

  • Gender
    Male
  • Location
    Russia
  • Interests
    Server and network administration, programming, software development. Lego and Lego Technic MOCs. Gaming.

Contact Methods

  • Website URL
    https://jtcf.ru/
  • Github
    JohnTheCoolingFan
  • Discord
    johnthecoolingfan

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. Oh crap, forgot to subscribe to the topic. Thanks @going for your work on this!
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. @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.
  11. 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.
  12. 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.
  13. 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.
  14. 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/
  15. 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/
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines