Jump to content

c0rnelius

Members
  • Posts

    54
  • Joined

Everything posted by c0rnelius

  1. This happens on both the Rock64 and Renegade and I would think other boards using the RK3328 SoC.. The fix is to patch, compile and in this case, re-flash u-boot. The attachment patch has been tested on U-Boot v2022.07/10 HDMI output appears to be broken on 6.1.y "in my experience". So if Manjaro has moved to that kernel, that would explain why HDMI is no longer working. 003-rk3328-set-VOP-QoS-to-high-priority.patch
  2. The boot partition is flagged ESP, which the PI3 does not support. Model: Generic MassStorageClass (scsi) Disk /dev/sdd: 32.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 4194kB 273MB 268MB primary fat32 esp 2 273MB 4106MB 3834MB primary ext4 Removing the ESP flag from the boot partition should allow the image to boot on both the RPi3 and RPi4. This can be easily done using gparted. if you are comfortable using the command line: sudo parted /dev/XXX set 1 esp off
  3. sudo wget https://raw.githubusercontent.com/canonical/cloud-utils/main/bin/growpart -P /usr/local/bin/ sudo chmod +x /usr/local/bin/growpart # assuming we are resizing an ext4 partition "/dev/mmcblk1p1": sudo growpart /dev/mmcblk1 1 sudo resize2fs /dev/mmcblk1p1
  4. My efforts into this are done. I was asked to make it boot and get it functioning, not to produce images for the masses. I think as that goes, I did as much. Sorry the kernel doesn't have everything "that everyone ever wanted" ticked on, but that wasn't a concern of mine at the time. With that said, I added support for it in the defconfig, if you or someone else wants to compile their own kernel for those images, you are more than welcome too. Honestly, I would suggest people check the commit: https://github.com/armbian/build/pull/4247 and help provide proper Armbian support. Thanx
  5. c0rnelius

    Odroid M1

    Someone went through the trouble to update and re-submit; https://lore.kernel.org/linux-rockchip/20220930051246.391614-1-aurelien@aurel32.net/T/#t If to lazy, you can pull it from here; https://github.com/pyavitz/debian-image-builder/tree/feature/patches/rockchip/rk356x/odroidm1/5.19 Last I heard everything worked but the eMMC, but that was "fixed" in V3. So hopefully that's fine now.
  6. A 'common' way with the current setup would be to load the overlay using extlinux. example: /boot/extlinux/extlinux.conf fdtoverlays ../rockchip/overlays/rockchip-rk3399-opp-2ghz.dtbo I don't know if its currently supported and if it is and you created the overlay, that's how you would load it at boot.
  7. What rkbins are you using? I've been using RKBIN_ELF="rkbin-master/bin/rk35/rk3568_bl31_v1.24.elf" RKBIN_RAM="rkbin-master/bin/rk35/rk3568_ddr_1560MHz_v1.13.bin"
  8. 9bx154, open an issue or create a PR with what you want ticked on. --> https://github.com/pyavitz/debian-image-builder defconfig -> rockchip64-rk356x_defconfig
  9. I'll add it to the build and see what people report. Thanx.
  10. Vendor u-boot needs to be purged from the eMMC: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5S#The_Boot_order_between_eMMC_and_SD_card I drop test imgs and kernels here: https://github.com/pyavitz/binary/releases/tag/images What was last reported; 5.19.3-2022-08-22 boots but no m.2, nor proper eth led functions. 5.19.6 I was told it booted, but then upon powering down the device it wouldn't come back. No other info given. Only change between 5.19.3 and 5.19.6 was a defconfig adjustment. Not tested; 5.19.8-2022-09-10 pin-ctrl added in hopes it brings up the m.2 and a custom led patch for the eth ports. Can open an issue there or find me on IRC / Discord.
  11. I think I can help here as I'm already working on this off and on. The problem I have is I don't own the hardware, so I'm not going to be submitting any thing to Armbian. But so far "as I'm told by the tester" I have the board booting and everything working except the m.2 and eth leds. Those two bits are a WIP and I'm currently waiting for the tester to get back from holiday so he can see if its working now. As for submitting the work to Armbian. I'd be happy to point whom ever to what I've done so far and help where I can.
  12. If you open the dts file for said board, you'll see something like this a few lines down from the top -> model = "Hardkernel ODROID-C4"; Whatever you put in there is what will spit out the model. You can name it -> model = "Hookers and Flapjacks"; Although, beyond laughs I see no real point in changing this.
  13. I've also noticed using an overlay to overclock the RK3399 on 5.15.y doesn't work, although in my testing it does work fine on 5.17 / 5.18.y. One solution is to patch the rk3399-opp.dtsi and add a turbo-mode switch. This way the board can be overclocked on the fly with a simple `echo "1" > sudo tee /sys/devices/system/cpu/cpufreq/boost`. 013-rk3399-opp-overclock-2GHz-turbo-mode.patch
  14. What does your extlinux/extlinux.conf file look like? Without seeing the contents I can't be sure, but on its face it looks like it can't load the files, because it can't find them. For example; since you are now booting from a boot partition, it shouldn't be checking for `/boot/$file. Instead it should be loading the files from the `/` of the boot partition.
  15. Armv7 and Locales can sometimes be a bitch. Have you tried? sudo apt update; sudo apt install -y locales-all
  16. I'll start by saying I don't own the board, but as this has come up and seems to be a problem across many boards using the same SoC and bits, it would appear on its face that the fix is probably generally the same across them all. Give or take a few differences? My github reference to the issue: https://github.com/armbian/build/issues/1352#issuecomment-952077351 I've included two patches you could test that I made for 5.10.y as that appears to be the kernel ur using. One thing I do not mention in the github issue is I also include the following to /etc/modules # /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. bluetooth hidp rfcomm bnep hci_uart 002-sun50i-h5-orangepi-zero-plus2-rfkill-gpio.patch 001-sun50i-h5-orangepi-zero-plus2-bluetooth-support.patch
  17. I can't be 100% sure, but I believe I saw a pull request for this some time ago where some one removed some things related to the reboot issue. I haven't scanned through the patch set as of late, but in my testing the following is needed. Need to revert: drivers/gpu/drm/meson/meson_drv.c https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L524 https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L542 Add Odroid reboot: https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L2323 https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L2533 If you review the pull request, you can see where the revert and odroid power reset patch was removed: https://github.com/armbian/build/pull/3154/files As for mainline u-boot the only thing of real importance is the following revert: https://github.com/armbian/build/pull/3154/files#diff-65100acf19e202ac3f3980da554c205752ea3c67d08fc4a3b445d4397189d12fR36 With out it, the boards "especially the N2/+ will kernel panic, as the reserved memory "CMA pool won't be set correctly". So the patch forces the boards to be marked nomap, hence populated after uboot hands off to the kernel.
  18. I believe what is required is this commit added to the meson64 patch set. https://github.com/tobetter/linux/commit/a026e2e9f55116e81ed49f48d918fdb91e28eff6
  19. sudo apt install -y python3-pip; sudo pip3 install bpytop
  20. That's my N2+ burning on all cores running slightly under clocked. It is very rare if it ever gets to 50*C. So for sure the script comes in handy.
  21. I've seen that happen before and has more to do with how people set the systemd services on the OS up more than anything. Most services "if any?" don't account for the rc-local service, so sometimes putting a sleep on your script is the easiest route to take. Happy its working for you.
  22. On the unit make sure what the script is looking for is there `ls /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp` As far as I know, on Hardkernel, Armbian and my own image that is the only location that the trip point is located? I guess I should add a check in the functions there to give an error, instead of a bash cry? As for the trip points, I didn't develop anything and as far as I know in my testing that can be set to whatever? It doesn't have to be 35000, it could be 20000 if someone so wanted, which would just make the fan run all the time as the board idles higher than that. I place mine at 45000 as it seems like a happy medium when compiling on it.
  23. In the terminal execute: fan-ctrl -h This will show you a list of all the options available, which include the trip points you can set. Once you select a trip point the script takes note of the choice you made and runs its self. Your trip point is now set and the fan will spin up at the given temp you chose. So in rc.local from that point on you just need to use the run function: fan-ctrl -r You can look over the script here to see what its actually doing: https://github.com/pyavitz/scripts/blob/master/fan-ctrl
  24. Remove all this from /etc/rc.local: [Service] ExecStart=/usr/local/bin/fan-ctrl -r &>/dev/null Type=oneshot RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF sudo systemctl enable odroid-fan-ctrl # Options Odroid N2 Trip Point Usage: fan-ctrl -h -1 65°C -2 55°C -3 45°C -4 35°C -r Run -u Update The script is downloaded already, correct? Set the trip point, for example: fan-ctrl -3 Now have the script run upon boot by adding it to /etc/rc.local. Example: #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. /usr/local/bin/fan-ctrl -r exit 0 That's it!
×
×
  • Create New...