SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Has anyone been able to run SLARM on a BeagleBoard/BeagleBone? It's completely open hardware, so seems like it'd be able to install, but I recall there may be difficult details depending which ARM architectures were actually ported to...
I used to run Void on my BeagleBone Black, never attempted Slack ARM on it. Although there's also the RISC-V Beagle V coming soon which looks very nice..
there's also the RISC-V Beagle V coming soon which looks very nice..
I am always on the quest for open hardware, and although I like pine64, their hardware is not completely open, and they're nearly always "out of stock." Therefoer, that Beagle V could fit the bill instead... but it's a new processor, so it wouldn't be slackware, slackware64, slackwarearm, or slarm -- we would have to make slisc-v; so If I was to try, and if I already had alternative linux (they mentioned mint at beagleboard.org), then it would be a matter of booting alternate linux from risc-v device, connect via ethernet (or usb-to ethernet converter) to more powerful device, download slackware source tree, and then rerun all the slackbuild scripts (I'd probably only start with a, ap, d, l, and n), offloading compilation to the more powerful device with distcc, mount a target file system for slackware's root, and then install all the resultant slackware packages in /tmp to the mounted rootfs with installpkg --root /moutnedrootfs ... That's what I'd probably try if I had a Beagle V...
There was an unofficial slackware port to RISC-V that started not too long ago in the slackware arm forum by sndwvs (creator of slarm64). He was targeting the BeagleV as well. The project is just starting out but it's something to keep an eye on.
Just pointing it out since the arm forum tends to get less visitors
and then rerun all the slackbuild scripts (I'd probably only start with a, ap, d, l, and n)
The Slackware build scripts are to be used on an existing Slackware OS, and whilst many of them will work without modification, there are a number that won't, requiring adjustment of hard configured settings in order to build, and a number of these are enablers for large numbers of packages.
And then there's platform specific issues with the toolchain that often require patching or changing versions; and there are the build system issues -- I've had to refresh libtool to support aarch64 on about 100 packages.
Rebuilding Slackware packages on an existing Slackware platform is quite a different thing to porting it from scratch!
The Slackware build scripts are to be used on an existing Slackware OS, and whilst many of them will work without modification, there are a number that won't, requiring adjustment of hard configured settings in order to build, and a number of these are enablers for large numbers of packages.
And then there's platform specific issues with the toolchain that often require patching or changing versions; and there are the build system issues -- I've had to refresh libtool to support aarch64 on about 100 packages.
Rebuilding Slackware packages on an existing Slackware platform is quite a different thing to porting it from scratch!
What a fascinating puzzle. Out of curiosity, how do they introduce a new architecture to linux? I suppose kernel developers have to add the new ISA to the kernel, and create options in the kernel's configuration front ends to enable them; and then, if it is the very first device for the new cpu, do they just build image on another architecture, with configurations checked for new architecture, and bootloaders updated for new architecture, then flash image to the first drive to use the new cpu, and keep their fingers crossed that it boots? Or is there lower level procedures for first runs?
To digress a bit: of all foreign languages offered at University of Texas in 1987, Russian had the shortest line at registration. I would have had to wait hours to study spanish, french, etc. To make a long story short: I am fluent in Russian, and I visited Vladivostok in 1992! But according to LQ rules, content must remain in English.
Could you, Roman, provide any links to forum where slackware is commonly discussed in Russian?
Last edited by slac-in-the-box; 03-08-2021 at 03:08 PM.
What a fascinating puzzle. Out of curiosity, how do they introduce a new architecture to linux? I suppose kernel developers have to add the new ISA to the kernel, and create options in the kernel's configuration front ends to enable them; and then, if it is the very first device for the new cpu, do they just build image on another architecture, with configurations checked for new architecture, and bootloaders updated for new architecture, then flash image to the first drive to use the new cpu, and keep their fingers crossed that it boots? Or is there lower level procedures for first runs?
This document is now ancient (there may be a newer version) but it was the reference document for many years.
Normally you begin by building the Kernel and a base platform on a faster architecture (which is usually x86_64), then switch to native compilation (and as you said, which is what I do -- use a cross compiler via a tool such as distcc or icecream) as soon as possible because it's easier than cross compiling the whole OS.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.