I’ll have to disagree with you on the LX2K. It’s first and foremost a workstation. The chip itself is, as you said, meant for networking gear. The NXP chip can provide 1x QSFP+ ports, along the usual 4x SFP+ ports, which are available on the ClearFog CX LX2, while the Honeycomb lacks the QSFP+ port to keep costs down (lol).
But indeed, in day to day tasks, the Amlogic A311D2 and the Rockchip RK3588 will feel a bit snappier, especially if you haven’t compiled your programs to use 16 cores.
That was a nice read, although most of the stuff seemed fairly standard. Except the PXE. Don’t have experience with video acceleration yet though.
In other news:
At work, we have ordered an SBC based on i.MX8M Plus - I’ll be getting a new toy. Seems like a pretty nice thing for our uses. Iirc the GPU is a bit worse than the i.MX8X we’re using, but everything else is better. Although I foresee a lot of work to get that NPU running nicely with PyTorch. We’ll see.
Regarding my ranting about nonexistent ARM crypto acceleration on FreeBSD it seems the gods devils heard my prayers and got it working on 13.1:
Runtime Libraries and API
Assembly optimized code for OpenSSL has been added on powerpc, powerpc64 and powerpc64le. ce35a3bc852
The detection of CPU features accelerating crypto operations for ARMv7 and ARM64 has been fixed, speeding up aes-256-gcm and sha256 substantially. 32a2fed6e71f (Sponsored by Ampere Computing LLC and Klara Inc.)
This is how the shitty sata card behaves on rockpro64 when you try to use 2 disks. It starts to throw hard reset errors and finally die for good until you reboot.
Its not due to lack of power. Kernel is Linux 5.17.
Yes, the official Pin64 sata card sucks and everyone complains about it, but they never change it. It’s kinda sad, really. But other sata cards work fine on the rockpro64. I wonder if that sata card will have the same issues on the quartzpro64. I believe it will, otherwise all sata adapters would have problems on the rockpro64.
I got a new toy at work!
An industrial PC with i.MX8M Plus and 6 GB of RAM. Not a speed demon, but still a very nice thing, very well built. Now on to the fun of updating it to a recent software version.
Try void on it. I am interested in researching ARM next.
Welcome back. We missed you 
I could, but don’t have the time. Over here it’s exclusively Yocto.
Plus, well, the SoC is slow compared to what folks use as ARM desktops nowadays - it’s roughly comparable to Pi3+, except the memory.
I have come to realize that my perspective on this topic is… vastly different from what most people here represent.
I ported U-Boot to new boards, wrote device trees, and nowadays me checking out a new board comes down to specs and whether it has a Yocto BSP, or at least the pieces to build a BSP out of. Regular distros supporting ARM are not something I use or even look at.
Then I look at @ThatGuyB’s journey (sorry for not helping more), and damn… I circumvent most of those issues, or just know where to look?
I was thinking of learning Gentoo and get over those issues as well at some point. I’m currently fighting with Petitboot on the HC4, because the board refuses to reboot on most distros besides the official Ubuntu from hardkernel, so I was hoping this may fix it… I am somewhat doubtful.
Well, this is a generic ARM thread, so anything can be posted IMO. Also, keep in mind I’m a complete noob at this.
I’m running Void on the Pi 2 and it runs great. But obviously, porting OS is a bit of a pain and distro-hopping isn’t something I encourage. When you are used to a certain distro, just try to make that work for you, in the future, you’ll probably thank yourself for spending the time to make it work.
I mostly go with Void and Alpine, but I’m open to Gentoo and nixOS, only because binary distros can only get me so far without me not knowing what I’m actually doing.
So I’ve actually started the Gentoo journey on a Pi4 because i have some severe paranoia about having my monero wallets stolen.
I’m in the process of getting LXDE compiled and running on it.
To do this, i got distcc running on my pi server cluster in a container, that way the compiling stays on arm64 and its much faster than local stuff.
Congratz on your Gentoo action. But just to throw some more fuel to the flames, I’ve personaly seen some Linux exploits in the wild that don’t require any compiling. If someone can get remote code execution on your device, they can just do a wget shell-script | bash and run the malware anyway.
So whatever Linux distro you are running, if you have bad opsec, you’ll get pwned. Conversely, if you have a good digital hygiene, it doesn’t matter what Linux distro you are running.
Which is why, for mission critical stuff, I prefer to strip the OS down to its minimal possible size (less attack surface). I only figured out how to do that on Void, because xbps is very easy to work with and I managed to remove sudo and nvi (vi), which I couldn’t on other distros, because the package manager was seeing them as dependencies for the base system. On void it was the same, but I ignored them in the xbps.conf and voila, no more unwanted packages that aren’t actually necessary.
On a linux box like you mentioned (although I don’t have any crypto, which I probably should, but I still haven’t gotten on my feet properly yet), I would strip down everything including bash, wget and curl, which are widely used for attacks. That way, a malware could only run if it’s either compiled on my box, or if it was pre-compiled and delivered as a single binary containing all its libraries and dependencies and then somehow executed on my system, which would be pretty hard to do without tools like wget or curl to assist. But given that I run most stuff on ARM, this kind of attack may be even less possible, because most malware is compiled for x86_64.
Going back to Gentoo, I heard that it is pretty snappy on the Pi 4, but I don’t know what the comparison point was (i.e. Gentoo running on what else).
Forgot to mention that I haven’t tried to remove Bash from void, I probably should give it a go, but I think bash is used in certain xbps scripts, so I didn’t want to get rid of it altogether, but bash is such a mess that I should probably try and see for myself. My main user shell of void is oksh anyway, and root uses dash. Thankfully, the even more minimal Alpine runs ash instead.
The only reason I’m still sticking with Alpine is because I haven’t figured out how to run Void in diskless mode / frugal install. Apparently it is doable on nixOS, but on Alpine, it’s the default on RPis and I slightly understand how it works, so that’s why I stuck with it.
I’ll let you know when I get LXDE installed.
Most exploit POC’s I’ve seen have been python.
Most I’ve seen were java and shell script grabbing pre-compiled binaries.
While on Twitter I had seen someone post about the BeagleBoard AI-64 was released recently, interesting bit is it uses the Texas Instruments Jacinto TDA4VM which has deep learning, vision and multimedia accelerators. The price is $187.50 on DigiKey.
Link:
https://beagleboard.org/ai-64
As far as my own opinion of the BeagleBoard AI-64, looks interesting but the price point would still push me towards a higher priced Jetson Orin NX.
Whenever I deployed an ARM board for a secure platform, I remove Python to trim down the amount of exploit options that could be done. The the only downside in a “smart home/automated office” type environment far too many things rely upon Python so you’re stuck hardening the security and hope for the best.
Why do the replies always come in waves?
It shouldn’t be, to be honest. What you need is the right bootloader, the device tree, and a kernel compiled with appropriate drivers. As long as the distro’s kernel is ok, it should be quite easy, although you might need to extract the device tree and the bootloader from somewhere else.
@ThatGuyB @SgtAwesomesauce personally, I encourage everyone to learn Yocto - it’s not a distribution per se, but rather a framework to build your own, custom one (although a lot of people just run with the reference one, called Poky).
Basically, you build everything from pieces, which are then compiled together. From BSPs, I know there’s meta-odroid and meta-rasberrypi, supporting, respectively, Odroid and Pi boards.
Since you’re building it from sources, you can get absolutely minimal stuff - say, a working image under 100 MB. With bash and GNU coreutils it might go a bit higher, to 200 or so. It’s perfect if you want something stripped down.
On a different note, you can also use it to build LXC (and maybe VM) images.
If there’s any interest, we could start a separate thread and I’d be glad to help you get started. On another note, while niche, there are apparently some Yocto jobs on the market.
I don’t think it supports building on ARM, but it does not require a very powerful PC - if you’re willing to live builds overnight, something like an R5 3600 is enough. What it does need is a crapton of drive space, preferably on a decent SSD. 100 GB is the bare minimum, but I’d recommend 200, maybe even 300 if you want a graphical environment.
This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.
