Jump to content

tparys

Members
  • Posts

    198
  • Joined

  • Last visited

Everything posted by tparys

  1. In case there's some sort of rare RK3399 memory issue ... https://forum.armbian.com/topic/16889-nanopi-m4v2-only-2gb-ram-reported/
  2. Sounds like the install to disk probably didn't work smoothly? It may be as simple as copying missing /boot files from your SD card to your disk. Providing armbianmonitor -u on your working HC1 may provide more useful information.
  3. https://archive.armbian.com/tinkerboard/archive/ ?
  4. Reason I do that is that I've used this technique to backup (or obliterate) full OS images. If I rsync from an image that doesn't have that new directory, it'll wipe out the mount. If I have the mount in a tmpfs at a known location, that shouldn't happen.
  5. Make your changes to the image before you call rsync? /dev/shm/original is mounted rw unless you tell it otherwise. You monster
  6. Not sure serial transceivers (UARTs) can be configured to pass every bit rate, parity, start/stop bit combination. Maybe better to use a circuit to do this? For RS232 format data, you can always tie the data sender's TX pin to multiple data receiver's RX pins. Just don't tie TX pins together. For RS485 format data, you could have a large number of listeners on the same pins.
  7. Would a USB to quad serial adapter work? Those tend to be consistent boot-to-boot. https://www.amazon.com/dp/B08P24ZQ1B/
  8. As a possible out-of-the-box solution. Have you tried directly mounting the original image, and just rsync'ing that to your partitions? # mkdir /dev/shm/{original,current} # kpartx -av Armbian_21.02.1_Nanopim4v2_focal_current_5.10.12_desktop.img add map loop9p1 (253:0): 0 7258112 linear 7:9 32768 # mount /dev/mapper/loop9p1 /dev/shm/original # mount /dev/mmcblk0p1 /dev/shm/current # rsync -av --delete /dev/shm/{original,current}/ # umount /dev/shm/original # umount /dev/shm/current # sync I didn't try it (for obvious reasons), but that should reset pretty much all logs, passwords, user files, ssh keys, etc .. The verbose option should list everything that it's doing. Your mileage may vary. You might need to adjust if your build has two partitions. It may delete important things ...
  9. May be worth reading this thread for some background. May be more work than you might think ... https://forum.armbian.com/topic/17492-newbie-cpu-marvell-armada-370/ My understanding is that the Rockchip CPUs have device unique boot blobs as part of the boot sequence. I believe this would be the only RK3188, so would be a one-off, and may require substantial u-boot or kernel DTB work with the payoff being a somewhat older and under powered board (compared to more recent RK3399). You can certainly leverage the Armbian build system to generate a build for your board, but you might be stuck with testing/debug unless you can find someone with free time. You can take a look HERE to see what's required to add support for a new CPU family & board.
  10. Definitely not a Linux login prompt. I'm going to echo @Heisath and suggest it's probably an OpenVPN configuration thing. I'd pop the SD card / eMMC out, chroot in via a Linux laptop, and run "systemctl disable openvpn" (or whatever that service is). You can always start it after you boot up. Or just reinstall and start over. But I'd be careful on what you're enabling on reboot, and ensure it's configured correctly before you do so. (Edit) You can also enable the SystemD rescue shell by adding "systemd.debug-shell" to your kernel arguments, and using ctl-alt-f9 to drop to a rescue shell during a stuck boot. It'll give you a better idea of the offending application that's doing that to you. https://www.thegeekdiary.com/how-to-boot-into-rescue-mode-or-emergency-mode-through-systemd-in-centos-rhel-7-and-8/
  11. You're not wrong, but does the voltage not determine the CPU frequency? I suppose I'm unclear at what else was requested. And there does seem to be OPP data in the DTS, though not in a format I typically see. As well as a series of thermal trip points, which might be a better option to edit, as that will set off the Kernel's built-in controls to self-regulate temperature. It'd be pretty straightforward to make a DTS patch to drop all these values by 10 C. cpu_hot { temperature = <0x14c08>; // 85000 mC hysteresis = <0x7d0>; type = "passive"; phandle = <0x4c>; };
  12. For experimentation, I loaded the DTS patch I posted HERE, basically adding a PWM fan object to the DTB and hooking it up as a thermal zone cooling device on my M4V2. Not sure if there's any particular requirements. It's part of the configfs, so I suppose that needs to be in the kernel build? Not sure if there's any particular version requirements.
  13. Unless your board somehow doesn't support it, usually the best approach is to use dynamic CPU frequency scaling, or cpufreq. https://www.kernel.org/doc/html/v4.14/admin-guide/pm/cpufreq.html Though it's not ideal for big.little architectures, The best place to start is /etc/default/cpufreq. On my NanoPi M4V2, it looks like this: ENABLE=true MIN_SPEED=408000 MAX_SPEED=2016000 GOVERNOR=ondemand Which says that the Kernel is free to scale the CPUs up to 2.016 GHz whenever it needs it, and leaves it at 408 MHz when it doesn't. If you need more control, you can poke these values directly via the sysfs interface. For example my RK3399 has two policies, one for each CPU cluster. And I can set parameters for each one via scaling_{min,max}_freq. tparys@hobbes:/sys/devices/system/cpu/cpufreq$ ls */ policy0/: affected_cpus related_cpus scaling_max_freq cpuinfo_cur_freq scaling_available_frequencies scaling_min_freq cpuinfo_max_freq scaling_available_governors scaling_setspeed cpuinfo_min_freq scaling_cur_freq stats cpuinfo_transition_latency scaling_driver ondemand scaling_governor policy4/: affected_cpus related_cpus scaling_max_freq cpuinfo_cur_freq scaling_available_frequencies scaling_min_freq cpuinfo_max_freq scaling_available_governors scaling_setspeed cpuinfo_min_freq scaling_cur_freq stats cpuinfo_transition_latency scaling_driver ondemand scaling_governor
  14. So, I've been doing some reading, and found this ... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.rst Looks like a mechanism to dynamically load or unload device tree overlays live. Really the only change is that .dtbo files need to be compiled with symbols (-@) like this: dtc -@ -o myoverlay.dtbo myoverlay.dts And then you can load/unload those overlays after (or during) boot by doing something like this: # Creates the dynamic overlay mkdir /sys/kernel/config/device-tree/overlays/myoverlay # Load the dynamic overlay cat myoverlay.dtbo > /sys/kernel/config/device-tree/overlays/myoverlay/dtbo # Unload the dynamic overlay rmdir /sys/kernel/config/device-tree/overlays/fan/ Which got me thinking. Given that not all board support DTB overlays within u-boot, and u-boot support is generally all over the place, would it make more sense to do DTB overlay support in-kernel and not worry about what u-boot implementations support it or no? Heck armbian-config could potentially load/unload DTB overlays then and there without a reboot.
  15. Device Tree: http://ix.io/2WUK Based on my current understanding, I2S1 (ff890000) is a 3.5 mm audio jack, and I2S2 (ff8a0000) is HDMI. Sound via HDMI appears to work after fiddling with pulseaudio settings a bit. I've not gotten anything at all from the audio jack. I've traced that error here: https://elixir.bootlin.com/linux/v5.10/source/sound/soc/rockchip/rockchip_i2s.c#L427 Unfortunately, my device tree-fu is weak and have not wrapped my head around what's missing in the DTB, or what to do about it.
  16. Often times yes, but not always. For example, it is not set on my NanoPi M4V2 (rockchip64) by default ... https://github.com/armbian/build/blob/f2e9da1af5ef752bda42b8c9344a46fdf74d060d/config/bootscripts/boot-rockchip64.cmd#L34
  17. Explanation of what you're seeing: https://forum.armbian.com/topic/11366-alert-devmmcblk0p1-does-not-exist/?do=findComment&comment=120713 Short version is that the early boot is looking for your boot partition by UUID (sort of a unique fingerprint) and cannot find it. You might be missing a driver in the initramfs, have a drive that's not being powered correctly, or just a bad image. I would start in that shell, and see what MMC block devices you have (/dev/mmcblk*) or hard drives (/dev/sd*) that you're expecting. Also worthwhile is to check the kernel log ( " dmesg | more " ) and check to see if any important hardware failed to initialize, missing firmware, etc ...
  18. Yes, run "fsck" the drive, but you probably want to use "fsck -y" which will just attempt to fix things and not ask permission at each step. Also do this with the filesystem unmounted, otherwise possible filesystem damage. Also, may want to add the " fsck.repair=yes " to your kernel arguments. That will direct SystemD to automatically attempt repairs like these. It may make things worse with failing hardware, but generally will do the right thing for users who want things to just work. https://www.linux.org/docs/man8/systemd-fsck.html
  19. There appears to be a lot of good looking information in this post, though do have some questions on what you did, while I'm unpacking everything in this post ... Your post references "rk3399-som-rk3399v2", but the Armbian default u-boot setup uses "rk3399-nanopi-m4v2". There's also a number of duplicate sections. Your "rt5651_card: " already exists on the Armbian DTS as "/rt5651-sound" and shouldn't need to be added. I'm curious what file you started with, and a little puzzled what needs to be fixed in the existing builds. Also your edits appear to edit the top level RK3399 DTS, where I'm uncertain whether those changes are appropriate to all boards that use it.
  20. So, I wasn't actually testing your latent psychic powers. Mostly just seeing if you had useful notes or resources handy that you could share. But if you think it'd help, clock summary here: http://ix.io/2WG7 The big issue that I (and a few other boards) have is a bunch of kernel spam every time the system tries to make sound ... [ 176.476379] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22 [ 176.477552] rockchip-i2s ff890000.i2s: Fail to set mclk -22 [ 176.478065] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22 [ 181.759856] rockchip-i2s ff890000.i2s: Fail to set mclk -22 [ 181.760364] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22 [ 181.762463] rockchip-i2s ff890000.i2s: Fail to set mclk -22 [ 181.762961] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22 [ 181.764570] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22 [ 181.765069] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22 Obviously something wrong with the clock definition in the DTB, and probably in the main RK3399 kernel dts, and may be worth trying to solve for everyone if possible.
  21. Neato. Thanks for documenting this process. Hopefully will help others. When you get to it, would be interested to see if the PREEMPT_RT patches make a difference for you.
  22. Unless someone else can confirm this behavior on another N2, you might just have a bad power supply. https://forum.armbian.com/forum/31-sd-card-and-psu-issues/ It may also be worth trying the HardKernel images and see if you can reproduce that fault there, to narrow down whether it's a fault with the image, or with your hardware. Without further information, there's not much here to go on.
  23. Building a Debian or Ubuntu image is relatively easy. But getting the boot sequence right is often time challenging. Often times there's little patches here and there to handle some "little thing" the hardware designers did, and if they didn't mainline whatever they did (which doesn't always happen), you're stuck with resolving changes by both the Linux kernel developers and the vendor's software team. This consumes a fair bit of maintainers' time, and is the primary reason it's not easy to just add one more board. If you can get a shell to the vendor's software image, and can't find the device tree (DTB), do something like this: $ dtc -I fs -o dump.dts /proc/device-tree You can compare it to what's in the current mainline kernel here: https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/armada-370.dtsi. To give you an idea of what the file does, it basically tells the kernel what's on the board. Power regulators, operating points, which buses are enabled, etc ... The other option is to see if you can find the vendor's published kernel sources. Per the GPL, they're required to publish any modified changes. Often times these are listed as Armbian "legacy" kernels. However, this isn't always the easiest to find. If you can find the version number for the kernel and u-boot, that will make your life a lot easier to resolve any differences with mainline. And to reiterate what @Heisath mentioned, be careful overwriting parts of the boot sequence. Recovering a CPU with a broken boot sequence is no fun. It may be required to set up a TFTP server and boot via PXE, or load the boot loader serially.
  24. My NanoPi M4V2 is still throwing I2S errors to console. I for one would be interested in any of your notes on how the I2S clocking is set up in the DTB.
  25. You might be in microcontroller territory at those signaling rates. I've done something similar with the stock Ubuntu 16.04 (4.4) kernel, but I'm not going to say it's the most reliable, and I'm not sure I'd recommend it. If you must do that, I'd also suggest locking your application to a single core with sched_setaffinity(), and avoid any calls to sleep(), usleep(), or nanosleep(). The kernel scheduler does not have the granularity you want. Hammer gettimeofday() in a busy loop to do your timing.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines