Jump to content

schwar3kat

Moderators
  • Posts

    241
  • Joined

  • Last visited

Other groups

Contributor/Maintainer

Profile Information

  • Location
    Auckland New Zealand

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Are you logged in as root? Your overlay_prefix=rockchip in the built image, so the menu should be visible under System then Hardware and should show all rockchip dtbo's. This board is a work in progress, so probably there is stuff missing and not working. Look in /boot/dtb/overlay to find available overlays. Drop the overlay_prefix and the .dtbo if you add them manually into armbianEnv.txt Reboot to activate. Those beginning with rockchip may work but I suspect that rockchip-RK3568B2 may be different there are no guarantees for a WIP board. Perhaps the suppliers image has overlays that you could harvest.
  2. Devices not installed on the board are generally enabled using device tree overlays. I don't have your board, but I did this some time ago with an Orange Pi Zero. Tutorial I used UART1 and PA7 From the tutorial: Add two lines to /boot/armbianEnv.txt to tell the Orange Pi Zero to use PA7 for PPS and uart1 for GPS NMEA messages overlays=uart1 pps-gpio param_pps_pin=PA7 You may not need to edit the file manually, you can add overlays from armbian-config, System, Hardware (you can see which overlays are available for your device). Overlays may have different names for different boards and families. If you can't find one for your board, it may be that nobody has created one yet.
  3. What board is it? If you can find a similar board, that would be a good starting point otherwise this is not a simple undertaking. It's not just the CPU, it's the board and integrated devices. These must be defined in a device tree. Each of the devices has to have an appropriate driver compiled into the kernel.
  4. @Tearran I changed the function name in my example to menu_init (because that would be a more accurate description). I have opened an issue on https://github.com/armbian/configng/issues/26 where the discussion could continue. Also feel free to pm me. Regards Kat
  5. @Tearran Bear in mind I'm not experienced with bash, so expect some ignorance 😄 Perhaps some kind of standard initialization function if it exists, could be triggered first as each script is parsed, setting initialization variables could be included as a standard part of any function script. And a similar menu folder initialization script could be included in any folder. One of those variables could set visibility. Another could set menu text, allowing dynamic menu text based on runtime requirements and possibly other options could be added if required. Any logic could be used to set those variables. To illustrate with an example of what I am imagining. Maybe something like this: (excuse my bash if it is bad or not feasible) # @description Do something useless. # # @exitcode 0 If successful. # # @options none # menu_init function triggered first by menu creation routines if it exists function menu_init(){ # # Only display menu option if internet connection is available # wget -q -t 1 --timeout=5 --spider http://github.com if [[ $? -ne 0 ]]; then menu_item=false else menu_item=true fi menu_text='Do something useful' # this could override the description as the menu text if it exists } function group::string() {s echo "Doing something" return 0 }
  6. I watched this week's video, and have a question about Joey's configng presentation. If my understanding is correct then the directory/folder that contains the script function determines the menu group, and the script header description determines the menu item wording. How can we include/exclude a script in the menu based on a runtime condition, like it is possible in armbian config? E.g. depending on a file or executable existing. How can we include/exclude a script group in the menu based on a runtime condition like it is possible in armbian config?
  7. @InfernalWolf666 As you have provided no logs, I can't see what Armbian image you have used. Your board is very new and it is likely that things are still missing from the upstream Kernel and the legacy build . In such cases the legacy build is often more complete than the current build. Those are device tree overlay files that you have found, however they are from another source and another board and are not relevant. Hardware devices that are not included by default on the board are usually not included in the default device tree. They would normally be added as device tree overlays. They are not drivers, they just map the hardware addresses so that the devices can be addressed by software. Drivers are generally included in the Kernel if they exist in the mainline Kernel or have been added as patches into the Armbian build. Device tree overlays can be applied through armbian-config, System, Hardware. (possibly not relevant but included for your understanding) Screenshots of armbian-config from a legacy build: (From a console type armbian-config) There are a number of overlays available for Opi5+ but I don't see anything related to your issue use the arrow keys to scroll. I suspect that your device may not currently be supported by the build that you are using. EDIT: According to the download page, you need to enable orangepi-5-ap6275p overlay from Hardware menu of armbian-config and reboot.
  8. I don't see this load to early issue on any of my boards, perhaps it is specific to your board. Please note that cpufrequtils is deprecated and has a number of issues with various boards that are unlikely to be addressed. (the other issue with cpufrequtils not being enabled by default for all boards has been addressed).
  9. Good point about I wouldn't have noticed, because personally, I haven't seen a need to use this armbian-config functionality but people are apparently using it so what do I know? The main issue, as I understand it, is that an armbian-config function doesn't work as it could reasonably be expected to work. I will mull over and test an idea and perhaps I can come up with a simple way to control expectations based on the ENABLED state. Edit: AR-1883
  10. I can confirm that in current images that I examined, in /etc/default/cpufrequtils, ENABLE is set to false. In older images that I examined ENABLE was set to true. This affects all boards. Without ENABLE being set, the armbian-config CPU speed governor settings simply don't work. Normally when cpufrequtils is installed, and a CPU driver exists, then the installer sets ENABLE to true. But cpufrequtils is pre-installed by Armbian build. Before logging a Jira issue I thought that I should investigate further to try and understand what had changed led me to this change tagged as [HIGHLY CONTENTIOUS CHANGE]. @rpardini do you have any insight into this change or advice?
  11. What are you plugging into the USB3 ports? Is your power supply capable of supplying enough current? If you measure USB3 inline voltage does it drop when you plug in the device? I am running the same Kernel version on OPi 5+ and my USB3 ports work with externally powered HDD's. Kernel and firmware upgrades disabled on mine.
  12. Because you are not using Armbian build for your u-boot, we can't know what might be wrong or missing. Armbian build documentation Have you tried to dd your entire SD card? You might need to shrink your image if not copying to an identical or larger SD card. Old instructions still work
  13. I think that something like this should work (I've done similar in the past, but I'm working from memory, so I may have missed something): Flash the new SD card with the same OS image used for the original card (a similar image may also work if u-boot isn't too different). Boot the card and allow it to expand the partition (or expand the partition using gparted or similar to about 80-90% of the SD card). Back up /etc/fstab from the new SD card to a safe location (it's a good idea to backup the /boot directory as well). Mount the new SD card RW on a Linux computer. You will need to be root or sudo su for most of the following. Delete all directories and files except for the /boot directory and it's contents from the new SD card. The new SD card root file system should now only contain /boot and it's contents. Rename /boot to /boot-backup Copy all files retaining permissions and attributes including /boot directory from the original SD card to the new SD card. https://www.makeuseof.com/preserve-file-permissions-in-linux-while-copying-them/ Replace /etc/fstab on the new card with the fstab that you backed up. Or edit the /etc/fstab on the new SD card '/' to match the UUID in your backed up fstab (this method only required if your original has extra non standard fstab entries). Change the UUID in /boot/armbianEnv.txt to match the entry in /boot-backup/armbianEnv.txt. (something like rootdev=UUID=f0920bd6-7fea-42cb-a9cd-3db938a68382). It should also match the '/' UUID in /etc/fstab. Good luck and let us know how it goes.
  14. Just started - and I can see it configured in the Makefile. "obj-$(CONFIG_BLK_DEV_RBD) += rbd.o" Halfway through - and it's built the module object. "rdb.o" Completed - and I can see the file "rdb.o" in the image in "/lib/modules/5.10.160-rk35xx/kernel/drivers/block" which is correct. (Do you have this in your image?). /boot/config-5.10.160-legacy-rk35xx contains "CONFIG_BLK_DEV_RBD=m" as expected. Looks okay as far as i understand, but I'm no expert. Did you save your new configuration after selection and exits? Your second build on the same clone should be faster because of caching.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines