There had been speculation for years that Apple would create it own chips for the Mac. It finally happened in 2020 with the introduction of what they call the M1 chip which was basically a beefed up version of the SOCs they’ve been using in their phones. They’ve been steadily adding to the lineup since but have not yet completed the transition away from Intel.
It basically made Apple the instant sales leader for ARM based conventional computers.
Less than a year before Apple moved from the IBM processor I purchased a $5K system from apple… It was great for two years, then it you couldn’t even use the browser, wanted an update to which there was none…
That’s when I moved to Linux… on the G5
My wifes Mac (from her company) is an M1, didn’t know it was an ARM architecture… Didn’t know where apple dug it up…
It seems odd that you say this…
I thought it already ran on these Macs… ?
LightBurn currently runs under Rosetta in Mac. It’s actually called Rosetta 2 and is the second iteration of Rosetta which was first used with the PowerPC → x86 transition. It offers basically seamless system-wide emulation of x86 for ARM.
Apple’s done a very good job with the implementation to the point where even device drivers and games work acceptably well.
Just speculating but I would have thought it was the iPad(iPadOS) which also ran on Apple ARM chips which really got them thinking of scaling their custom ARM SOC upto desktop capabilities.
The Mac ARM chips are fast and powerful and to run x86 MacOS apps they have a virtual machine tool called Rosetta which allows x86 apps to run on these new Apple ARM chips. So yes, LightBurn does already run on Apple ARM PCs but they do it through emulation so LightBurn devs don’t yet have to change anything.
Thanks to both… seems like a band aid more than a solution. Anytime you add a layer of code, you slow it down… been there, done that… can’t be helped…
At least you guys cleared it up for me. Once they shafted me without lubrication, I dumped all my remaining Apple products.
They also promised Apple records they’d stay out of the music business…
Technology gets smarter and speeds forward at an ever increasing rate, I feel like I get more dumb and slower at an ever increasing rate. 
When I was switching from the EE track to CS track in the late '80s I was working as a electronics tech and was asked to help the local ME who was redesigning the manufacturing floor and adding some nice new equipment like surface mount solder station which was relatively new back then. We got to know each other a bit and one day he says to me that I should switch and get an ME degree.
When I asked why he hold me it was because I could get my degree, travel the world for 3 or more years and still easily get hired as an ME because the laws of Physics won’t have changed. I told him I was switching to Computer Science because it changes so much. Following hardware and software takes at least 2 hours / day scanning news sites and reading up on how the new stuff works. Never was great at any one thing and it’s getting more difficult to keep up let along remember stuff from 10, 20, 30+ years ago.
But have been a UNIX fan since using it in the '80s and so happy LightBurn supports Linux even if it’s only on x86. That hardware is cheap these days.
Ditto… Linux is here because AT&T (UNIX) cost a left nut and first born for it…
I keep Tux on my table just to remind me of it all…
Yes, this is really feasable. But the problem is Lightburn doesn’t support any kind of integration with octoprint (or other software).
When I use octoprint with prusaslicer, I have a single button to send gcode to octoprint.
If i want to use it with LB I have to save gcode, the open it in octoprint. It works, but a little annoying.
Instead to have LB running on RaspberryPI I would prefere to have some API or IPC from LB to others. But is just my 2c.
I used usbIP to do remote control with a Raspberry Pi running the usbIP at the laser and since my desktop is also Linux, it’s running there too. I think there are Mac and Windows options like this.
And I was engraving cork outside with a diode laser with a fan on it. Running a high power laser without in-person monitoring is not recommended.
I found a USB client server that’s free for one connection, the server runs on any version of raspberry pi from 0 to 4B it’s easy to install and start.
In light burn it shows up as just another USB port. A one time sever license is $49 and gives you all the options, it’s called VirtualHereUniversal
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
@bhimio’s recent post Bringing back the raspberry pi (not finished) rekindled this subject. Thought I’d come back to this to see if things have changed to potentially improve the situation.
I’ve made some effort to update to latest current LightBurn and to provide for latest Ubuntu 2020.04.6 libraries.
This latest set of changes come with several quality of life improvements and brings this to what I would consider a perfectly usable state. Try this if it’s of any interest to you.
Basically, everything I’ve tried works with the major exception of the camera. However, the camera is detected and trying to use the camera no longer crashes LightBurn.
I believe this is due to difference in symbols provided by some native libraries in Raspberry Pi OS vs Ubuntu but not certain. Would appreciate if anyone can track this down.
Summary of changes:
What doesn’t work:
Installation and Usage:
Here is a list of the Ubuntu .deb files that were extracted and included in the 7zip files:
gstreamer1.0-plugins-bad_1.16.3-0ubuntu1_amd64.deb
libgstreamer-plugins-bad1.0-0_1.16.3-0ubuntu1_amd64.deb
liborc-0.4-0_0.4.31-1_amd64.deb
libgpg-error0_1.37-1_amd64.deb
libgcrypt20_1.8.5-5ubuntu1.1_amd64.deb
libgstreamer1.0-0_1.16.3-0ubuntu1.1_amd64.deb
libwrap0_7.6.q-30_amd64.deb
libasyncns0_0.8-6_amd64.deb
libzstd1_1.4.4+dfsg-3ubuntu0.1_amd64.deb
libtirpc3_1.2.5-1ubuntu0.1_amd64.deb
libsystemd0_245.4-4ubuntu3.22_amd64.deb
libpulse-mainloop-glib0_13.99.1-1ubuntu3.13_amd64.deb
libpulse0_13.99.1-1ubuntu3.13_amd64.deb
libgstreamer-plugins-base1.0-0_1.16.3-0ubuntu1.2_amd64.deb
liblz4-1_1.9.2-2ubuntu0.20.04.1_amd64.deb
libdbus-1-3_1.12.16-2ubuntu2.3_amd64.deb
libapparmor1_2.13.3-7ubuntu5.2_amd64.deb
I would say performance is surprisingly good. I’m using the same Pi3 with 1GB RAM as in the original post. Anything newer should work much better.
[EDIT] 2023-11-25 Updated the library archives to correct packaging issue.
Somehow your shell script is not loading the libs it needs and cant find libzstd (which in cant even start loading whithout)
A few questions:
@berainlb Having the same issue as @bhimio … Working with a RPi 4 running Debian GNU/Linux 11 (bullseye), kernel version 5.15.84-v8+. I have uncompressed the two 7z library archives to the LightBurn folder… all libs except libzstd.so.1 seem to load just fine. Here is the output:
Dynarec for ARM64, with extension: ASIMD CRC32 PageSize:4096 Running on Cortex-A72 with 4 Cores
Params database has 30 entries
Box64 with Dynarec v0.2.5 12c40a5b built on Oct 25 2023 06:25:21
BOX64: Prefer Emulated libs
Counted 25 Env var
BOX64 LIB PATH: /home/jwebster/Downloads/LightBurn/lib_amd64/lib/x86_64-linux-gnu/:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/pulseaudio/:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/gstreamer-1.0/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/
BOX64 BIN PATH: ./:bin/:/usr/local/bin/:/usr/bin/:/bin/:/usr/games/
Looking for /home/jwebster/Downloads/LightBurn/LightBurn
Rename process to "LightBurn"
Using native(wrapped) libusb-1.0.so.0
Error loading needed lib libzstd.so.1
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5MultimediaWidgets.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5PrintSupport.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Widgets.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Multimedia.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Gui.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5SerialPort.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Network.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Xml.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Core.so.5
Using native(wrapped) libpthread.so.0
Using emulated /lib/x86_64-linux-gnu/libstdc++.so.6
Using native(wrapped) libm.so.6
Using emulated /lib/x86_64-linux-gnu/libgcc_s.so.1
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libdl.so.2
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Error loading one of needed lib
Error: loading needed libs in elf /home/jwebster/Downloads/LightBurn/LightBurn
Since the script reports using emulated libs in /home/jwebster/Downloads/LightBurn/lib/, I also tried copying libzstd.so.1 to that folder (thinking it may be a PATH/environment issue)… same result. To ensure the environment variables were getting set properly, I added an export comand to the launch script. Here are the relevant variables printed:
declare -x BOX64_LD_LIBRARY_PATH="/home/jwebster/Downloads/LightBurn/lib_amd64/lib/x86_64-linux-gnu:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/pulseaudio:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/gstreamer-1.0"
declare -x BOX64_PREFER_EMULATED="1"
I’m very keen to get this working with BOX64, so I appreciate all of the effort you have put into this to get it working, and hope you have a few suggestions.
I haven’t attempted this with anything other than Raspberry Pi OS and a difficult attempt with Ubuntu that was impractical due to the Raspberry Pi 3 I’m running.
Can you first try this with Pi OS “September 22nd 2022” to see if things work correctly at all? I’ve done this in a bubble and have had no independent verifications that this works so would like to confirm first. I suspect this should work fine with a newer edition but I haven’t tested that way.
The balance of native and emulated libraries makes this whole affair a bit tricky. The emulated libraries I’ve controlled by bundling those libraries from Ubuntu 2020.04 but the native libraries being different can create different symbol dependencies that need to be reconciled.
@berainlb I’m happy to try… but can’t locate the image for Pi OS “September 22nd 2022”… I looked at both downloads.rasberrypi.com and releases.ubuntu.com:
Can you share a link (or, perhaps, it isn’t Sep 22 2022 but another release?)
Look here please. You need the 64-bit edition:
https://downloads.raspberrypi.com/raspios_arm64/images/raspios_arm64-2022-09-26/
Or for full edition:
https://downloads.raspberrypi.com/raspios_full_arm64/images/raspios_full_arm64-2022-09-26/
I can’t recall which i installed.
@berainlb OK, completely fresh install of raspios_arm64-2022-09-26… and followed your 12 Nov post “Installation and Usage:” list verbatim. Fortunately (or, unfortunately, depending on perspective), it didn’t work. Same exact error running a completely different raspi OS version. I say “fortunately” because, if it worked on your system, there is likely a small tweak to make this work on many systems. Screenshot of all of the output below:
Let me know your thoughts.
