Slackware - ARMThis forum is for the discussion of Slackware ARM.
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.
All my previous ARM devices are Raspberry Pi's. I usually get my hardware from adafruit.com or Amazon. I am not seeing specific individual hardware components for sale on Amazon for the Orange Pi. There are a few all in one kits but nothing more for the Orange Pi.
Can someone please recommend an online retailer for Orange Pi hardware?
I am not exactly sure what I plan to use this board for just yet. I plan to run Slackware, of course. Ideas are welcome.
All my previous ARM devices are Raspberry Pi's. I usually get my hardware from adafruit.com or Amazon. I am not seeing specific individual hardware components for sale on Amazon for the Orange Pi. There are a few all in one kits but nothing more for the Orange Pi.
Can someone please recommend an online retailer for Orange Pi hardware?
I am not exactly sure what I plan to use this board for just yet. I plan to run Slackware, of course. Ideas are welcome.
I dont's know about your board but I own an Orange PI Zero, it looks similar...
I bought an expansion board https://www.amazon.com/Makerfocus-Or.../dp/B071DM768M
maybe you can check the docs to see if it is compatible with your board, mine is running Slackwarearm current.
Is the Orange Pi R1 not supported? I haven't opened the packaging yet, so I could still possibly return it.
It may do, but it's not documented so you'd have to figure out. All of the U-Boot binaries are for either the A20 or H3 but the OrangePi R1 is an H5. I'll update the docs on the web site to make it more clear which models are supported. There only used to be one or two models, but the various models aren't all supported.
The R1 looks pretty weak -- I'm not sure you'd even be able to boot the installer on it due to only 256MB RAM. The minimum supported machine has 512MB RAM.
A development board might be a possibility. I am a bit concerned about the system requirements for -current with the R1.
Thanks for the heads up, I will have to do a bit more research. I may have to just return this board in the end. I don't think the person who gifted me this board for Christmas had any clue about what they were buying.
For certain tasks, this board is well suited, as for the SlackwareArm, then it is perfect for this board, since it does not have redundant services that consume memory.
For certain tasks, this board is well suited, as for the SlackwareArm, then it is perfect for this board, since it does not have redundant services that consume memory.
I have a Raspberry Pi 1 B+ (512 MB of RAM) running Slackware 14.2 and it idles at 31MB of used RAM. It almost never goes over 100MB of RAM used. As Stuart suggested, the issue is that the installer requires more than 256MB of RAM in most cases to complete the process. I could probably make a very minimal installation with the Orange Pi R1 and skip larger packages so that the installer can complete. Then after the fact I can cherry pick what I need.
I propose to make an image and install it on the SDcard, after which you can go 2 ways, 1 to boot and install it on the package or simply install it on your PC with SDcard support by means of ROOT=/mnt/sdcard installpkg <package>.txz
I have a Raspberry Pi 1 B+ (512 MB of RAM) running Slackware 14.2 and it idles at 31MB of used RAM. It almost never goes over 100MB of RAM used. As Stuart suggested, the issue is that the installer requires more than 256MB of RAM in most cases to complete the process. I could probably make a very minimal installation with the Orange Pi R1 and skip larger packages so that the installer can complete. Then after the fact I can cherry pick what I need.
The issue with the installer isn't to do with installing packages, it's that the compressed image has to be loaded in to RAM, uncompressed and subsequently held in RAM, with enough RAM left for the operations of the OS. The size of the installer is far larger than it used to be ten years ago when 256MB RAM was a huge amount on an ARM board.
For certain tasks, this board is well suited, as for the SlackwareArm, then it is perfect for this board, since it does not have redundant services that consume memory.
I'm not sure how this could work on Slackware ARM: The H5 is a 64-bit machine and there are no "sun50i" models available in the 32-bit Kernel. What have you seen that makes you think it's perfect?
I'm not sure how this could work on Slackware ARM: The H5 is a 64-bit machine and there are no "sun50i" models available in the 32-bit Kernel. What have you seen that makes you think it's perfect?
for this, the kernel is built as arm64 (cross compile) and works in a 32 bit environment. so I ran the
SlackwareArm on rockchip rk3399 at the beginning
That board is fine for an experiment board and probably some low voltage robotics. Everything is raspberry pi like everything is debian/ubuntsomething (thems just the big market segments) but if its I2C hardware it'll work on anything with I2c pins, same withe serial comms and one wire chips and there aren't any leds, transistors etc made specificaly for raspberry pis
If someone gave me one of those and if I could not return it or felt like a challenge I'd try doing this:
1) Download armbian's 32bit orangepi r1 image put it on an sdcard and compile a uboot binary for the opi-r1 there is a defconfig available for that board. Maybe you can get way doing it on a raspberry pi. Its not a difficult thing to compile.
2) Since drmozes sez the install image is too bit for 256mb ram after its unpacked use the current slackwarearm minirootfs.and install what else I need afterwards.
3) That opi-r1 according to Xunlong is a H2 Quad-core 32-bit Cortex-A7 so Id be hoping that the slackwarearm current /dtb kernel and initrd will work after I put it all together on an sdcard.
Edit: On a closer look I realise there is usb available via a 13 pin function interface but no usb ports on this board so Its not really set up for web cams unless you want to nut out connecting on on the function interface. Maybe a challenge too far.
Last edited by justwantin; 01-20-2019 at 03:02 AM.
Reason: mostuff
I finally found some time to I install Slackwarearm-current on the R1 successfully. I used a micro usb to male usb cord to interface with my laptop. Then I wrote the u-boot binary to the 16MB SPI Flash using the orangepi_r1.u-boot-2020.01-rc4_1.bin.xz binary. I had to make some adjustments from the official documentation so that the OOM kernel feature would stop killing the slackware installer when I ran out of RAM. It was a bit tedious though, seeing as SPI Flash is read only. It was very time consuming reconfiguring U-boot at every power cycle. I am glad I bought my USB to UART serial adapter!
First I took out all automation and ran every u-boot command manually to have better control over whats running. This way the dropbear ssh daemon didn't start. I killed syslogd and klogd to glean a few more MB back. Then I formatted the SD Card with mkfs, to again, save the installer some effort.
The second thing I did was raise the (much higer) tx queue length on eth0 and lo. This made it possible for my very weak R1 to more quickly download files like the kernel firmware and other larger packages. I used this same trick to get Slackawrearm 14.2 to run in Qemu using the vexpress dtb. More about that in the warning blurb here: https://docs.slackware.com/howtos:ha...twork_settings It might very well be true that the qemu wiki doc is still accurate for 14.2.
There are slightly different commands to run for current. This is what I ran to adjust current.
Code:
# Raise txqueuelen on all interfaces
ifconfig eth0 down
pkill dhcpcd
ip link set eth0 qlen 10000
ip link set lo qlen 10000
ifconfig eth0 up
dhcpcd eth0
No more OOM killer after that.
Next....
The tricky part was optimizing the HTTP, TFTP, and, NFS services. TFTP was to grab the kernel, initrd, and DTB over the network and load them into RAM to boot into the installer with U-Boot. The HTTP mirror was abandoned, all except to allow me to download my tag files, since it was already set up. In earlier attempts, I tried to use the python2 and python3 HTTP Service modules, but those kept crashing due to the exceedingly slow download rate. I used apache instead to serve http. I am unsure if the new tx queue len network setting would allow python to be used. Apache was working so I didn't go back and test. NFS was used to carry out the installation.
Even with the faster speeds provided by NFS, I had to move the network connection on the NFS host to Gb ethernet. I stored the slackwarearm tree on an NVMe disk for more speed.
After all, I ended up with a very minimal installation. It runs though. I will be using it as a network tap. I still need to work out if I will use snort, suricata, or as simple as tcpdump with remote logging.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.