LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)
-   -   Orange Pi R1 (https://www.linuxquestions.org/questions/slackware-arm-108/orange-pi-r1-4175645879/)

mralk3 01-09-2019 07:42 PM

Orange Pi R1
 
I received an Orange Pi R1 for Christmas: http://www.orangepi.org/OrangePiR1/

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. :)

drmozes 01-10-2019 09:10 AM

Quote:

Originally Posted by mralk3 (Post 5946674)
I received an Orange Pi R1 for Christmas: http://www.orangepi.org/OrangePiR1/

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. :)

This is the Orange Pi Plus 2E which are supported. I bought mine from AliExpress.

mralk3 01-11-2019 12:52 PM

Is the Orange Pi R1 not supported? I haven't opened the packaging yet, so I could still possibly return it.

VicFer 01-12-2019 01:06 AM

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.

Bye

drmozes 01-12-2019 03:58 AM

Quote:

Originally Posted by mralk3 (Post 5947793)
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.

mralk3 01-12-2019 11:22 AM

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.

sndwvs 01-12-2019 01:08 PM

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.

mralk3 01-12-2019 01:38 PM

Quote:

Originally Posted by sndwvs (Post 5948223)
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.

sndwvs 01-12-2019 02:01 PM

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

drmozes 01-12-2019 02:48 PM

Quote:

Originally Posted by mralk3 (Post 5948230)
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.

drmozes 01-12-2019 03:03 PM

Quote:

Originally Posted by sndwvs (Post 5948223)
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?

sndwvs 01-12-2019 03:25 PM

Quote:

Originally Posted by drmozes (Post 5948268)
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?

the specification is written (and in the photo) H2 Quad-core 32-bit Cortex-A7

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

justwantin 01-20-2019 02:43 AM

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.

SCerovec 02-02-2019 02:59 AM

For what it is worth:

pulled a sd card from a fully working Orange PI PC and plugged it to a Orange PI Zero (the same CPU as R1 but mine has 512MB RAM).

Just works.

Do follow up for details in a thread of it's own.

mralk3 03-04-2021 05:15 PM

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.


All times are GMT -5. The time now is 08:55 PM.