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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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!
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).
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).
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.
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
