Orange Pi Plus 2E now tested in -current

stormtracknole · 02-05-2018, 03:09 PM

Quote:

Originally Posted by drmozes

The Orange Pi is supported by Slackware ARM directly, and there is only one Kernel package and its accompanying modules package:

Code:

a/kernel_armv7-4.14.15-arm-1.txz
a/kernel-modules-armv7-4.14.15_armv7-arm-1.txz

I'm not sure what the link is you're thinking of about the Raspberry Pi.

I was thinking more of a regular install in that you can select from more than one kernel via lilo or grub. I guess I haven't wrapped my mind yet on how things work in arm world. You have answered my question though. Thank you as always!

drmozes · 02-05-2018, 03:30 PM

Quote:

Originally Posted by stormtracknole

I was thinking more of a regular install in that you can select from more than one kernel via lilo or grub. I guess I haven't wrapped my mind yet on how things work in arm world. You have answered my question though. Thank you as always!

u-boot has a powerful command line interface, and a scripting language (which I've not explored myself), so you don't need a menu of any kind. If you wanted to be able to downgrade to the previous kernel, after you'd installed a new one (just in case the new one didn't turn out well), you could preserve the existing stuff:

Code:

root@zippy:~/ac/source/kde# cd /boot/
root@zippy:/boot# ls
README-kernels.txt  System.map-armv7-4.14.15  dtb-4.14.15/          uImage-armv7@         uinitrd-armv7-4.14.15
README.initrd@      config-armv7-4.14.15      initrd-armv7@         uImage-armv7-4.14.15  zImage-armv7@
System.map-armv7@   dtb@                      initrd-armv7-4.14.15  uinitrd-armv7@        zImage-armv7-4.14.15
root@zippy:/boot# mkdir previous
root@zippy:/boot# cp -fa initrd-armv7* dtb-4.14.15 zImage-armv7* previous/
root@zippy:/boot# cd /lib/modules/
root@zippy:/lib/modules# ls
4.14.15-armv7/
root@zippy:/lib/modules# mkdir previous
root@zippy:/lib/modules# cp -fa 4.14.15-armv7/ previous/
root@zippy:/lib/modules# #upgradepkg blahblah kernel and kernel-modules packages
root@zippy:/lib/modules# mv previous/* . # because ugpradepkg will wipe the modules from the previous package's installation

This way if it didn't work out, you could interrupt u-boot, and load the previous DTB, kernel and zImage manually (the installation instructions tell you how to do that for the installer, and it's no different to the OS; apart from you're loading it from local storage rather than over the network).
I've never actually had cause to do that though - if my system breaks, I boot in to the installer and fix it from there, since you could mount the OS and upgradepkg the kernel packages to the previous version (if you had the previous package).

Penthux · 02-05-2018, 04:27 PM

Quote:

Originally Posted by drmozes

This is unnecessary as the Orange Pi has an RTC.

DOH!

stormtracknole · 02-05-2018, 04:34 PM

Quote:

Originally Posted by drmozes

u-boot has a powerful command line interface, and a scripting language (which I've not explored myself), so you don't need a menu of any kind. If you wanted to be able to downgrade to the previous kernel, after you'd installed a new one (just in case the new one didn't turn out well), you could preserve the existing stuff:

Code:

root@zippy:~/ac/source/kde# cd /boot/
root@zippy:/boot# ls
README-kernels.txt  System.map-armv7-4.14.15  dtb-4.14.15/          uImage-armv7@         uinitrd-armv7-4.14.15
README.initrd@      config-armv7-4.14.15      initrd-armv7@         uImage-armv7-4.14.15  zImage-armv7@
System.map-armv7@   dtb@                      initrd-armv7-4.14.15  uinitrd-armv7@        zImage-armv7-4.14.15
root@zippy:/boot# mkdir previous
root@zippy:/boot# cp -fa initrd-armv7* dtb-4.14.15 zImage-armv7* previous/
root@zippy:/boot# cd /lib/modules/
root@zippy:/lib/modules# ls
4.14.15-armv7/
root@zippy:/lib/modules# mkdir previous
root@zippy:/lib/modules# cp -fa 4.14.15-armv7/ previous/
root@zippy:/lib/modules# #upgradepkg blahblah kernel and kernel-modules packages
root@zippy:/lib/modules# mv previous/* . # because ugpradepkg will wipe the modules from the previous package's installation

This way if it didn't work out, you could interrupt u-boot, and load the previous DTB, kernel and zImage manually (the installation instructions tell you how to do that for the installer, and it's no different to the OS; apart from you're loading it from local storage rather than over the network).
I've never actually had cause to do that though - if my system breaks, I boot in to the installer and fix it from there, since you could mount the OS and upgradepkg the kernel packages to the previous version (if you had the previous package).

Thank you for the very detailed explanation.

Dunc. · 02-18-2018, 05:33 AM

Quote:

Originally Posted by drmozes View Post
This is unnecessary as the Orange Pi has an RTC.

It does have an RTC but due to some poor design decisions it can't have a battery backup because the power rail of the RTC is not separated from the rest of the device. If you require a battery backed RTC then add a second one. I did this for my mythtv box. I loaded the driver and set the time like this.

Quote:

#!/bin/sh

# script to start real time clock rtc
# crude but it works

echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-0/new_device #driver for rtc
sleep 1
if [ -e /dev/rtc1 ] ;
then
logger "rtc1 found, setting time from hw clock to system clock"
hwclock -f /dev/rtc1 -s # Change system time
else
logger "no rtc1 found"
fi

This leaves one problem. rc.6 and rc.S act upon the wrong RTC. I used the $CLOCK_OPT and set it to CLOCK_OPT="-f /dev/rtc1". A proper solution is to have a configuration file and a script rc.RTC called rc.6 and rc.S to set and save local time.

Hope this helps.

Regards,

Duncan

drmozes · 02-18-2018, 10:38 AM

Quote:

Originally Posted by Dunc.

It does have an RTC but due to some poor design decisions it can't have a battery backup because the power rail of the RTC is not separated from the rest of the device. If you require a battery backed RTC then add a second one. I did this for my mythtv box. I loaded the driver and set the time like this.

Ah of course! There's no battery on the board - I hadn't realised that.
I think that the only useful thing about having an RTC without battery back up is (which is the full extent of my current knowledge of RTCs) that at least it means that the clock will maintain time even if the machine is under continuous load (which tends not to happen if there's no RTC).