lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<Armbian-Discord> <T​onymac32> Very nice
puto14 has joined #armbian-rockchip
puto14 has quit [Quit: Client closed]
<Armbian-Discord> <a​mazingfate> Anyone can overclock rk3288 to 2.0 GHz? I have a board based on firefly rk3288 reload. After command echo 1 > /sys/devices/system/cpu/cpufreq/boost I can see CPU max MHz: 2208.0000 but the cpufreq is locked at 600MHz, I can see kernel error rockchip_cpuclk_pre_rate_change: Invalid rate : 24000000 for cpuclk. Where does this 24MHz freq come from? It's not in the cpu opp table.
<Armbian-Discord> <T​heBug> I mean my understanding is you can sure try, if you have the overlay or want to mess with DTB to modify it you may be able to get it to come up at higher rclock rate.
<Armbian-Discord> <a​mazingfate> There is already a patch adding higher cpu clk:https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip-5.19/RK3288-1.8GHz-and-boost.patch
<Armbian-Discord> <T​onymac32> I have run the Tinker board at 2.0 GHz
<Armbian-Discord> <T​onymac32> But it's been a long time
<Armbian-Discord> <a​mazingfate> since rk3288 is an obsolete chip in 2022
<Armbian-Discord> <T​onymac32> shrugs
<Armbian-Discord> <T​onymac32> it kicks the shit out of anything A53 based
<Armbian-Discord> <T​onymac32> 😄
<Armbian-Discord> <T​onymac32> my only argument against using it at this point is the difficulty in getting some packages in 32 bit, and it's power consumption is legendary
<Armbian-Discord> <T​onymac32> (It was my introduction to Armbian when I brought up the Tinker board, so I might be biased) 😄
<Armbian-Discord> <T​heBug> lol
<Armbian-Discord> <M​icroLinux (Salva)> We need an affordable 8xa55 at decent lithography
<Armbian-Discord> <M​icroLinux (Salva)> Or why not, 8xa510
<Armbian-Discord> <a​mazingfate> Yeah rk3568 can just replace rk3288. But anyway rk3288 has better mainline support in multimedia.
<Armbian-Discord> <T​onymac32> Yep. Which is what matters, so we're always running obsolete hardware.
<Armbian-Discord> <T​onymac32> The rk3568 GPU is pretty much a door stop isn't it?
<Armbian-Discord> <T​enkawa> rk3568 is really meant for disk io in all fairness though (which that it does very well)
<Armbian-Discord> <T​enkawa> at least my rk3568 does
<Armbian-Discord> <T​onymac32> I highly doubt that's its designed function, but it should have better I/O handling being so much newer
<Armbian-Discord> <T​onymac32> The RK team make media processors like Amlogic does, they just happen to do Chromebook stuff as well
<Armbian-Discord> <l​anefu> More ChromeOS servers
<Armbian-Discord> <T​onymac32> ChromeOS 🤮🤮🤮🤮🤮🤮
<Armbian-Discord> <T​onymac32> Who put up the content about "yay make chrome boxes out of your old PC's!!!". Despicable. Truly an evil concept
<Armbian-Discord> <T​onymac32> 😆
<ghostInTheSSH[m]> What is needed to make armbian work for a board? I am trying to get a build going for my soquartz modules (which are very siilar to quartz64a)
<Armbian-Discord> <T​onymac32> Ugh I can't make heads or tails of the documentation at present for contribution, but you need a board config file (the conf files), and if needed the device trees patched into u-boot and the kernel. You should be able to use the quartz64a as a decent starting point
<Armbian-Discord> <T​onymac32> https://docs.armbian.com/
<Armbian-Discord> <T​onymac32> NOW TO BE CLEAR
<ghostInTheSSH[m]> Armbian-Discord: I was just about to ask if it was this commit lol
<Armbian-Discord> <T​onymac32> this targets the media kernel, and no one anywhere except 150Balbes does anything with that/knows anything about it
<Armbian-Discord> <T​onymac32> It is his private project within Armbian
<ghostInTheSSH[m]> What is the media kernel?
<ghostInTheSSH[m]> Oh
<Armbian-Discord> <T​onymac32> it's 150balbes's kernel
<Armbian-Discord> <T​onymac32> no idea, I don't use it
<Armbian-Discord> <T​onymac32> 😄
<ghostInTheSSH[m]> I swear I built a quartz64a image yesterday using the "current" option for q64a.
<Armbian-Discord> <T​onymac32> perhaps @IgorPec has better info about it, I can't keep up when things are done randomly
<Armbian-Discord> <T​onymac32> well, the versions are all named "legacy", "current", etc
<Armbian-Discord> <T​onymac32> but they are their own board family, not the rockchip64 ones
<Armbian-Discord> <T​onymac32> I would very much prefer the contributions be made to the project in general, but that seems too much to ask
<Armbian-Discord> <T​onymac32> 😉
<ghostInTheSSH[m]> <Armbian-Discord> "<T​onymac32> well, the versions..." <- So I built the current of the media kernel?
<Armbian-Discord> <T​onymac32> yes
<ghostInTheSSH[m]> So 2 questions.
<ghostInTheSSH[m]> 1. Is that why the quartz64a artifact on github uses a different kernel version from other builds?
<ghostInTheSSH[m]> 2. Is that why the commit/PR you sent (authored by 150balbes) has a lot of files which appear to be patches to get applied to the kernel?
<Armbian-Discord> <T​onymac32> yes, if that kernel didn't have any rk3566/8 support before that board was added, it all had to be done there
<Armbian-Discord> <T​onymac32> that is also not a clean PR, so it has unrelated stuff in it
<ghostInTheSSH[m]> <Armbian-Discord> "<T​onymac32> Ugh I can't make..." <- For things like a raspberry pi compute module 3/4 or the clones (I am interested in the soquartz hence joining the rock chip chat). Is the dts/dtsi, uboot, or conf affected by the specific carrier board that gets used?
<Armbian-Discord> <T​enkawa> since the carrier board contains hardware definitions and parts I would say yes
<Armbian-Discord> <T​enkawa> Just like with the RPI the Waveshare boards and Foundation boards use much different hardware for different models
<Armbian-Discord> <T​onymac32> it could be, depending on what it has on it
<Armbian-Discord> <T​onymac32> I would expect that would be handled by a device tree overlay
<Armbian-Discord> <T​onymac32> (that's what I would do)
<Armbian-Discord> <T​onymac32> but, you could also just hardcode a device tree for your specific instance
<Armbian-Discord> <T​onymac32> so soquartz module as a dtsi and the carrier as a dts
<Armbian-Discord> <T​onymac32> that includes the dtsi
<Armbian-Discord> <T​enkawa> yeah you usually start with one for the module and add one for the io board
<Armbian-Discord> <T​enkawa> makes it much easier to interchange this way
<Armbian-Discord> <T​onymac32> right, however we aren't going to have a board conf for every possible carrier board
<Armbian-Discord> <T​enkawa> exactly
<Armbian-Discord> <T​onymac32> that's why I suggested an overlay
<Armbian-Discord> <T​onymac32> does media kernel do extlinux? In that case I can't help with how to implement the overlay
<Armbian-Discord> <T​enkawa> but overlays won't all work at boot on certain older modules if memory serves without major boot tweaking
<Armbian-Discord> <T​onymac32> since the armbian tools aren't set up for that
<Armbian-Discord> <T​onymac32> hmmm, "older modules" being previous soquartz release levels?
<Armbian-Discord> <T​enkawa> yeah
<Armbian-Discord> <T​onymac32> I lost my interest in accomodating the Pine dev cycle long ago
<Armbian-Discord> <T​onymac32> support the newest and forget the rest
<Armbian-Discord> <T​enkawa> I know in the rpi space setting up extlinux for that took some "creativity"
<Armbian-Discord> <T​onymac32> the rock64 was such a cf it nearly broke me for ever using their hardware again
<Armbian-Discord> <T​enkawa> and it doesnt even use normal u-boot
<Armbian-Discord> <T​onymac32> well, an RPi is a pretend linux box. 😉
<Armbian-Discord> <T​enkawa> haahaa touche
<Armbian-Discord> <T​enkawa> lol
<Armbian-Discord> <T​onymac32> it's an RTOS on a GPU allowing linux to exist on the peripheral ARM cores 😄
<Armbian-Discord> <T​enkawa> Any of you have a PBP by chance?
<Armbian-Discord> <T​onymac32> somewhere here
<Armbian-Discord> <T​enkawa> I need to see if any of you can check your pci-e link speed if its on
<Armbian-Discord> <T​onymac32> ah, not used
<Armbian-Discord> <T​enkawa> I'm curious what it maxes out at
<Armbian-Discord> <T​enkawa> I get mine in a few days finally
<Armbian-Discord> <T​onymac32> if the board and the adapter are designed properly it should be able to do PCIe 2 link speeds ( 5 GT/s)
<Armbian-Discord> <T​enkawa> ok good.. I'll leave my x4 drive in the other machine
<Armbian-Discord> <T​onymac32> but that's an overlay since it's not officially supported (Rockchip seems to remove features based on their partners inability to use them)
<Armbian-Discord> <T​enkawa> I have 2 drives and didn't think it could utilize the faster speed
<Armbian-Discord> <T​enkawa> yeah this is my other rk3399 with a old drive
<Armbian-Discord> <T​enkawa> pci 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
<Armbian-Discord> <T​onymac32> yeah, so we have a PCIe 2 overlay you could enable if you're using Armbian
<Armbian-Discord> <T​onymac32> what is the board though
<ghostInTheSSH[m]> I am using a Super6c which is a 6 raspberry pi CM4 carrier.
<ghostInTheSSH[m]> It provides power, an ethernet connection (via an on board switch), pcie, and microsd for each board
<ghostInTheSSH[m]> Sorry NVME interface not pcie.
<Armbian-Discord> <T​enkawa> just a RockPro64 but the drive itself doesmt support it
<Armbian-Discord> <T​enkawa> its right on the drive
<Armbian-Discord> <T​onymac32> oh ok, lol
<Armbian-Discord> <T​enkawa> Yeah... my other drives all support it... just don't want to waste higher bandwidth on this drive
<ghostInTheSSH[m]> ghostInTheSSH[m]: Sorry I thought the question was directed at me. Maybe there is some reply/thread stuff not carried over via bridge.
<Armbian-Discord> <T​enkawa> are you using mainline kernel?
<ghostInTheSSH[m]> If possible, but I can use modifications or patches if needed.
<Armbian-Discord> <T​enkawa> if not you are going to want https://github.com/raspberrypi/linux/blob/rpi-5.x.y/arch/arm64/boot/dts/broadcom/bcm2711-rpi-cm4.dts 5-x.y=version ie 5-10.y
<Armbian-Discord> <T​enkawa> or arm if using 32 bit
<Armbian-Discord> <T​enkawa> https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm64/boot/dts/broadcom/bcm2711-rpi-cm4.dts appears to need arm/boot/dts/bcm2711-rpi-cm4.dts too
<ghostInTheSSH[m]> (at the specific kernel version I want to build)
<Armbian-Discord> <T​enkawa> I'll have to defer to others on that board
<Armbian-Discord> <T​enkawa> (I don't have a rk3566 handy)
<Armbian-Discord> <T​onymac32> looks like the right one. What dts files reference that dtsi though?
<ghostInTheSSH[m]> Looks like someone used the SOQuartz + CM4-IO DTS to boot on the super6c board I have https://forum.manjaro.org/t/manjaro-arm-on-the-pine64-soquartz-cm4-with-deskpi-super6c-carrier-board/117445
<ghostInTheSSH[m]> It looks like the microcenter near me has a Raspberry Pi CM4 IO board, so I'm going to cop that, it might make some of this easier to get off thr ground with.
<Armbian-Discord> <T​onymac32> cool
<Armbian-Discord> <T​enkawa> mc for the win 🙂
<Armbian-Discord> <T​onymac32> closest one to me is 40 miles
<Armbian-Discord> <T​enkawa> @Tonymac32 as you I think know.... I'm in the home office city
<Armbian-Discord> <T​onymac32> lol
<Armbian-Discord> <T​enkawa> Its just evil.... we did have 2 stores here at one time... only 1 noe
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-rockchip
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-rockchip
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-rockchip
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-rockchip
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-rockchip
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-rockchip