Login

Recent searches

No recent searches

Search options

Only available when logged in.
fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

9.8K
active users

fosstodon.org: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#rockpro64

0 posts0 participants0 posts today
FrankM<p>Ein neuer Forumbeitrag: <a href="https://linux-nerds.org/topic/1676/rockpro64-mainline-kernel-6.13.0-1197-ayufan" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">linux-nerds.org/topic/1676/roc</span><span class="invisible">kpro64-mainline-kernel-6.13.0-1197-ayufan</span></a> <a href="https://nrw.social/tags/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rockpro64</span></a> <a href="https://nrw.social/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a></p>
Chris Vogel<p>Follow-up to <a href="https://chrichri.ween.de/o/289704403f2f4abea071c3d9cc9f2ab8" rel="nofollow noopener noreferrer" target="_blank">this note</a>.</p> <p>Dragan had asked me to do <strong>repeated power-cycle tests</strong> with different kernel versions using the patched dtb for <a href="https://chrichri.ween.de/t/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a> to make sure the kernel <a href="https://chrichri.ween.de/t/oops" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>oops</span></a> wouldn't still be an issue.</p> <p>I learned that cutting the power of the device could kill the <a href="https://chrichri.ween.de/t/lpddr4" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>LPDDR4</span></a> <a href="https://chrichri.ween.de/t/ram" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RAM</span></a>. This is documented in the specification referenced on the <a href="https://wiki.pine64.org/wiki/ROCKPro64#Datasheets_for_Components_and_Peripherals" rel="nofollow noopener noreferrer" target="_blank">RockPro64 wiki page</a> for <a href="https://files.pine64.org/doc/datasheet/rockpro64/SM512M32Z01MD2BNP(200BALL).pdf" rel="nofollow noopener noreferrer" target="_blank">Micron LPDDR4 Mobile LPDDR4 Datasheet</a> as stated on page 37 in <em>Uncontrolled Power-Off</em>:</p> <blockquote> <p>An uncontrolled power-off sequence can occur a maximum of 400 times over the life of the device.</p> </blockquote> <p>I never had heard about this before! <strong>Cutting power without shutdown can kill my RAM?</strong></p> <p><strong>show dmesg and shutdown</strong></p> <p>To get all the debugging information I needed I wanted the system after booting to print <code>dmesg</code> to the serial console, wait a short time and then actually shutdown.</p> <pre><code> root:~# cat /root/bin/dmesg_and_shutdown.sh #!/bin/bash # a small script that outputs dmesg to serial # console, waits 20 seconds and shuts down dmesg &gt; /dev/ttyS2 # show a message how to stop this script and wait 20 seconds echo "Will shutdown in 20 seconds - to stop me call 'pkill dmesg_and_shut'" &gt; /dev/ttyS2 sleep 20 echo "shutdown -h" &gt; /dev/ttyS2 shutdown -h now # a cronjob that runs after each boot root:~# crontab -l @reboot /root/bin/dmesg_and_shutdown.sh </code></pre> <p><strong>powercycle the board</strong></p> <p>I took the time needed for a complete cycle of booting, showing dmesg, waiting and shutting down: well below 2 minutes.</p> <p>To automate the power cycle I used an <a href="https://chrichri.ween.de/t/esp8266" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>esp8266</span></a> based power switch made by <a href="https://chrichri.ween.de/t/sonoff" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Sonoff</span></a> (Powr2) running <a href="https://github.com/letscontrolit/ESPEasy" rel="nofollow noopener noreferrer" target="_blank">ESP Easy</a> (mega-20210503).</p> <p><a href="https://chrichri.ween.de/t/espeasy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ESPeasy</span></a> offers a simple scripting language I used to powercycle after 120 seconds of being switched on:</p> <pre><code> On System#Boot do gpio,12,0 gpio,13,1 endon On button#button_state do if [blue_led#blue_led_state]=1 gpio,13,0 timerSet,1,2 else gpio,13,1 gpio,12,1 timerSet,1,0 timerSet,2,0 endif endon On Rules#Timer=1 do gpio,12,0 timerSet,2,1 endon On Rules#Timer=2 do gpio,12,1 timerSet,1,2 endon </code></pre> <p>Pressing the button on the Sonoff device toggles between:</p> <ul> <li>blue led off: timers disabled, relay on permanently</li> <li>blue led on: timers switch the relay off for 5 seconds, on for 120 seconds and then repeat</li> </ul> <p><strong>logging</strong></p> <p><code>minicom</code> logged the serial output to a file.</p> <p>Further down the <a href="https://chrichri.ween.de/t/rabbithole" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RabbitHole</span></a> I went when looking at the resulting logfile…</p>
Chris Vogel<p>Follow-up to <a href="https://chrichri.ween.de/o/aa4e54ecd04e44e1a13ef079fddffa2f" rel="nofollow noopener noreferrer" target="_blank">this note</a></p> <p>Meanwhile Dragans changes to the dtb file helped my testing setup to boot without eMMC. So I could test booting manually from scsi devices like on my production system.</p> <p>Looking for some simple instructions on how-to do this failed and I put together the following information.</p> <p>u-boot on <a href="https://chrichri.ween.de/t/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a> uses <a href="https://git.sr.ht/~chrichri/RockPro64_u-boot_SATA_software_RAID_howto#copy-u-boot-environment-to-spi" rel="nofollow noopener noreferrer" target="_blank">variables written to flash</a>. The important ones for choosing a device/kernel to boot:</p> <pre><code> # this u-boot will look for scsi devices only boot_targets=scsi # it will scan the devices for bootcmd=bootflow scan </code></pre> <p>Since I have a <code>boot.scr</code> in my <code>/boot</code> the <a href="https://docs.u-boot.org/en/latest/develop/bootstd/script.html" rel="nofollow noopener noreferrer" target="_blank">bootmeth</a> seems to be script. There's also the source of that file <code>boot.cmd</code> available and from there I extracted the commands to run on the u-boot console to start any kernel/initrd/dtb I could find on disk:</p> <pre><code> # initialize pci bus pci enum # show devices on pci pci # reset bus and scan for scsi devices scsi reset # get partition table scsi part # find boot files ls scsi 0:1 /boot # load armbian defaults load scsi 0:1 0x800800 /boot/armbianEnv.txt # replace the xyz on the following line with the # filesize output by 'load' above env import -t 0x800800 xyz # write uuid of partition to variable partuuid part uuid scsi 0:1 partuuid # arguments passed to the kernel on boot setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}" # look for available images, initrds and dtbs ls scsi 0:1 /boot # get the dtb directory, **uInitrd** and the vmlinuz # from the output to use with the following 'load' commands load scsi 0:1 0x02080000 /boot/ load scsi 0:1 0x06000000 /boot/ load scsi 0:1 0x01f00000 /boot//rockchip/rk3399-rockpro64.dtb booti 0x02080000 0x06000000 0x01f00000 </code></pre> <p>At this point I only needed to wait for the Pine64 sata ctrl to arrive to test the <code>current</code> kernel with the same ctrl used in my production system.</p> <p>So I went back to the fork in the tunnels and took the other way down the <a href="https://chrichri.ween.de/t/rabbithole" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RabbitHole</span></a>…</p>
Chris Vogel<p>Follow-up to <a href="https://chrichri.ween.de/o/c25a04650dc942b5b728dd8e48133f9f" rel="nofollow noopener noreferrer" target="_blank">this note</a>:</p> <p>At one of the times the <code>current</code> <a href="https://chrichri.ween.de/t/armbian" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Armbian</span></a> <a href="https://chrichri.ween.de/t/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a> kernel didn't crash, but booted on my <a href="https://chrichri.ween.de/t/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a> I installed <a href="https://chrichri.ween.de/t/gotosocial" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>GotoSocial</span></a> and yes: no more <a href="https://github.com/superseriousbusiness/gotosocial/issues/3840#issue-2881055359" rel="nofollow noopener noreferrer" target="_blank">strange error messages</a> running it. <strong>The only time I remember that I updated a linux kernel to make an application work.</strong></p> <p>Preparations to get the production system running with the newer kernel:</p> <ul> <li>in case of problems I'd need to know my way back to boot the old kernel: u-boot recap and learning</li> <li>test suspected problems with the <a href="https://chrichri.ween.de/t/sata" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>sata</span></a> <a href="https://chrichri.ween.de/t/pcie" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pcie</span></a> ctrl beforehand (get a second Pine64 sata ctrl for the test system)</li> </ul> <p>Meanwhile Dragan had <a href="https://lore.kernel.org/linux-rockchip/cover.1740748439.git.dsimic@manjaro.org/T/#u" rel="nofollow noopener noreferrer" target="_blank">patched the device tree</a> and asked to check on a few reboots whether this would make a difference or cause any regressions.</p> <p>Further down the <a href="https://chrichri.ween.de/t/rabbithole" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RabbitHole</span></a> the tunnel forks…</p>
Chris Vogel<p>Follow-up to <a href="https://chrichri.ween.de/o/ea126f38d1584f7aa92ff37ddcdf50f1" rel="nofollow noopener noreferrer" target="_blank">this note</a>:</p> <p>I decided to test whether <a href="https://chrichri.ween.de/t/gotosocial" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>GotoSocial</span></a> would work on the <a href="https://chrichri.ween.de/t/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a> using the <code>current</code> instead of the <code>legacy</code> <a href="https://chrichri.ween.de/t/armbian" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Armbian</span></a> kernel before risking problems upgrading my production <a href="https://chrichri.ween.de/t/yunohost" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>yunohost</span></a>.</p> <p>I have a similar testing setup: old mechanical drives instead of SSDs, a different PCIe SATA controller, an additional eMMC.</p> <p>The additional eMMC I need to boot from, because for some reason the <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052610" rel="nofollow noopener noreferrer" target="_blank">PCIe SATA ctrl didn't work, when u-boot initializes the controller before the kernel</a>.</p> <p>Installing the <code>current</code> kernel on my testing setup I found it not working: no console on hdmi, no network. Forgot to install the newer dtb (<a href="https://en.wikipedia.org/wiki/Devicetree" rel="nofollow noopener noreferrer" target="_blank">device tree binary</a>) as well.</p> <p>With <code>currrent</code> kernel and dtb from <a href="https://chrichri.ween.de/t/armbian" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Armbian</span></a> installed the system booted half of the times I switched it on. Asking around on the <a href="https://pine64.org/community/#chat-platforms" rel="nofollow noopener noreferrer" target="_blank">rock64 chat</a> I met Dragan Simic who greatly helped me to get further down the <a href="https://chrichri.ween.de/t/rabbithole" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RabbitHole</span></a>…</p>
Chris Vogel<p>On my <a href="https://chrichri.ween.de/t/yunohost" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>yunohost</span></a> I tried to update <a href="https://chrichri.ween.de/t/gotosocial" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>gotosocial</span></a> from <code>0.17.4~ynh1</code> to <code>0.18.1~ynh1</code> and the update failed.</p> <p>GotoSocial just showed some cryptical error messages when started.</p> <p><span class="h-card"><a href="https://gts.superseriousbusiness.org/@dumpsterqueer" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@dumpsterqueer@superseriousbusiness.org</a></span> traced the <a href="https://github.com/superseriousbusiness/gotosocial/issues/3840" rel="nofollow noopener noreferrer" target="_blank">problem</a> back to a changed lib version used in the new GotoSocial version and the developer of the lib answered my <a href="https://chrichri.ween.de/t/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a> <a href="https://github.com/tetratelabs/wazero/issues/2383#issuecomment-2684617443" rel="nofollow noopener noreferrer" target="_blank">kernel would be too old</a>.</p> <p>The old <a href="https://chrichri.ween.de/t/armbian" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>armbian</span></a> legacy kernel is running, because … <em>I don't remember</em>.</p> <p>I need a kernel update for my <a href="https://chrichri.ween.de/t/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rockpro64</span></a>.</p> <p>Down the <a href="https://chrichri.ween.de/t/rabbithole" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RabbitHole</span></a>…</p>
PublicLewdness<p>I used Pmbootstrap to install PostmarketOS onto my RockPro64. You pick a variety of options and settings then you choose which disk to install it to and whether you want fde or not. <a href="https://wiki.postmarketos.org/wiki/Installation/Using_pmbootstrap" rel="nofollow noopener noreferrer" target="_blank">wiki.postmarketos.org/wiki/Install...</a> <a href="https://bsky.app/search?q=%23postmarketos" rel="nofollow noopener noreferrer" target="_blank">#postmarketos</a> <a href="https://bsky.app/search?q=%23pine64" rel="nofollow noopener noreferrer" target="_blank">#pine64</a> <a href="https://bsky.app/search?q=%23rockpro64" rel="nofollow noopener noreferrer" target="_blank">#rockpro64</a><br><br><a href="https://wiki.postmarketos.org/wiki/Installation/Using_pmbootstrap" rel="nofollow noopener noreferrer" target="_blank">Installation/Using pmbootstrap...</a></p>
Joel P.<p>It's been a nice holiday break with relaxing <a href="https://mastodon.sdf.org/tags/bsd" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>bsd</span></a> projects. Final upgrade before heading back to $DAYJOB:</p><p>Upgrade to NetBSD 10.1 on my <a href="https://mastodon.sdf.org/tags/pine64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pine64</span></a> <a href="https://mastodon.sdf.org/tags/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rockpro64</span></a> </p><p>I run ZFS on this ARM64 board with an NVMe SSD attached via PCI card.</p><p>Running well. dmesg:</p><p><a href="https://dmesgd.nycbug.org/index.cgi?do=view&amp;id=8133" rel="nofollow noopener noreferrer" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dmesgd.nycbug.org/index.cgi?do</span><span class="invisible">=view&amp;id=8133</span></a></p><p><a href="https://mastodon.sdf.org/tags/netbsd" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>netbsd</span></a> <a href="https://mastodon.sdf.org/tags/zfs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>zfs</span></a> <a href="https://mastodon.sdf.org/tags/aarch64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>aarch64</span></a></p>
SpaceWater<p>This thing has been a headache and a half to get up and running, but now is running so smoothly</p><p><a href="https://infosec.exchange/tags/nixos" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>nixos</span></a> <a href="https://infosec.exchange/tags/homelab" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>homelab</span></a> <a href="https://infosec.exchange/tags/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rockpro64</span></a> <a href="https://infosec.exchange/tags/pine64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pine64</span></a></p>
PublicLewdness<p>I tried OpenSuse on my RockPro64 and it worked with one hitch. I can't choose to have full disk encryption enabled. if I do it doesn't recognize any keyboard I have plugged in and I can't type in my FDE password. If I choose to not use FDE then it boots into the user login screen by which time my keyboard works. It took a bit of getting used to OpenSuse in terms of their package manager and other bits but I could see this being my main choice of distro on my RockPro64. FDE may not work properly on it right now but many distros don't even give the option for FDE on ARM64 so it's a step in the right direction.</p><p><a href="https://gameliberty.club/tags/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rockpro64</span></a> <a href="https://gameliberty.club/tags/opensuse" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>opensuse</span></a> <a href="https://gameliberty.club/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a> <a href="https://gameliberty.club/tags/security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>security</span></a> <a href="https://gameliberty.club/tags/privacy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>privacy</span></a></p>
balletproof vest<p>Can anyone just tell me in like a dozen simple steps or less how to install <a href="https://beach.city/tags/Debian" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Debian</span></a> onto a SATA disk in a <a href="https://beach.city/tags/RockPro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a> without fucking hammering nails directly into my forehead or reading a 438 page forum thread please for the love of god</p><p>If your answer starts with “maybe” or “I think” or “Just™️” please directly fuck off into deep space, I only want to hear from people who have actually accomplished this and not vague reply guy guesses</p>
Anachron :void:<p>Even though I don&#39;t think <a href="https://fosstodon.org/tags/Pine64" class="mention hashtag" rel="tag">#<span>Pine64</span></a> is going strong currently, I have to admit that my <a href="https://fosstodon.org/tags/RockPro64" class="mention hashtag" rel="tag">#<span>RockPro64</span></a> is very solid hardware and has no issues whatsoever.</p>
Josh :t_blink:<p>So far the <a href="https://fosstodon.org/tags/RockPro64" class="mention hashtag" rel="tag">#<span>RockPro64</span></a> and the <a href="https://fosstodon.org/tags/MangoPi" class="mention hashtag" rel="tag">#<span>MangoPi</span></a> MqPro have been a blast to tinker around with and to set up in their final forms/use case.</p><p>The <a href="https://fosstodon.org/tags/OrangePi" class="mention hashtag" rel="tag">#<span>OrangePi</span></a> Zero 2w has been a fine addition and has a promising future.</p><p>Both RPi zeros have steady and running well for their respective use cases (pi-hole and mini nas).</p><p>The <a href="https://fosstodon.org/tags/MilkVMars" class="mention hashtag" rel="tag">#<span>MilkVMars</span></a> has kind of been a disappointment since day one and not much has improved since then. Maybe it needs more time, but I just get more meh as it goes on.</p>
Josh :t_blink:<p>Beholden thy <a href="https://fosstodon.org/tags/SBC" class="mention hashtag" rel="tag">#<span>SBC</span></a> abomination of jank. A <a href="https://fosstodon.org/tags/MangoPi" class="mention hashtag" rel="tag">#<span>MangoPi</span></a> MqPro plugged into a <a href="https://fosstodon.org/tags/OrangePi" class="mention hashtag" rel="tag">#<span>OrangePi</span></a> Zero W2 that controls 2 <a href="https://fosstodon.org/tags/RaspberryPiZeros" class="mention hashtag" rel="tag">#<span>RaspberryPiZeros</span></a> (W &amp; 2W) and a <a href="https://fosstodon.org/tags/RockPro64" class="mention hashtag" rel="tag">#<span>RockPro64</span></a>.</p><p>So much janky awesomeness in one place, it’s almost too much to handle! I now “offically” feel like a SBC enthusiast</p>
Joel P.<p><span class="h-card"><a href="https://mastodon.sdf.org/@netbsd" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>netbsd</span></a></span> Just upgraded my Pine RockPro64!</p><p><a href="https://mastodon.sdf.org/tags/pine64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pine64</span></a> <a href="https://mastodon.sdf.org/tags/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rockpro64</span></a></p>
Joel P.<p>Finally got time to do a clean install of NetBSD10_RC5 on my <a href="https://mastodon.sdf.org/tags/RockPro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a> with an eMMC module.<br>Previously I had RC1 running for several months.<br>I have a PCIe M.2 card and a 500gb SSD; hence a breeze to backup key config files from RC1 and then restore once RC5 was up and SSD mounted.<br>Everything looks great 👍</p><p><a href="https://mastodon.sdf.org/tags/netbsd" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>netbsd</span></a> <a href="https://mastodon.sdf.org/tags/netbsd10" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>netbsd10</span></a></p>
Joel P.<p>I've been running NetBSD10_RC for months on my RockPro64 and only recently learned about using<br>/usr/sbin/schedctl -A 4,5<br>to force a process to use the faster CPUs. Hopefully this improves a daily ffmpeg job I have.<br><a href="https://mastodon.sdf.org/tags/NetBSD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>NetBSD</span></a> <a href="https://mastodon.sdf.org/tags/RockPro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a> <a href="https://mastodon.sdf.org/tags/pine64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pine64</span></a></p>
FrankM<p>Ein neuer Forumbeitrag: <a href="https://linux-nerds.org/topic/1555/rockpro64-mainline-kernel-6-8-0-rc3" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">linux-nerds.org/topic/1555/roc</span><span class="invisible">kpro64-mainline-kernel-6-8-0-rc3</span></a> 1555/rockpro64-mainline-kernel-6-8-0-rc3 <a href="https://nrw.social/tags/rockpro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rockpro64</span></a> <a href="https://nrw.social/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a> <a href="https://nrw.social/tags/mainline" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>mainline</span></a></p>
Shenzi Thinker Abouter<p>Conclusion: Linux 6.6 broke something and uboot can't deal with it</p><p>Tried 23.01, 23.07, 23.10, 24.01<br>All failed to boot 6.6.8</p><p>Downgraded kernel to 6.5.13 and it came up fine</p><p>Still need to test another platform (like quartz64 or rock64) but this is my result on rockpro64</p><p><a href="https://masto.asonix.dog/tags/sbc" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>sbc</span></a> <a href="https://masto.asonix.dog/tags/NixOS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>NixOS</span></a> <a href="https://masto.asonix.dog/tags/uBoot" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>uBoot</span></a> <a href="https://masto.asonix.dog/tags/RockPro64" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RockPro64</span></a></p>
Josh :t_blink:<p>I think I did it! I got <a href="https://fosstodon.org/tags/raid1" class="mention hashtag" rel="tag">#<span>raid1</span></a> set up on the <a href="https://fosstodon.org/tags/rockpro64" class="mention hashtag" rel="tag">#<span>rockpro64</span></a>. I got permissions all set and should be good to go there. Now I am in the slow process of transferring over files via the network- slow but steady.</p>
ExploreLive feeds
About