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
<DC-IRC>
<infinity_q> also debian: when will I get an update? lol
<DC-IRC>
<c0rnelius77> if you want Debian to break as much as Arch, use sid. You can also do the same with Ubuntu I believe by using devel. It will keep you in a state of rolling.
<DC-IRC>
<amazingfate> I've been doing a lot of backport work on jammy. Ffmpeg, obs-studio, nodejs, chromium, Kodi. You can always build the latest packages by yourself.
<DC-IRC>
<amdbartek> Will test it later today
<DC-IRC>
<lanefu> I've been using sid a lot lately. It's fun and doesn't break that often lol
<DC-IRC>
<efectn> arch is same too
<DC-IRC>
<efectn> it mostly work fine after updating
<DC-IRC>
<efectn> it mostly works fine after updating
<DC-IRC>
<infinity_q> yep, as long as you update frequently
<DC-IRC>
<efectn> it's funny to update 2-3 years old images 😄
<DC-IRC>
<infinity_q> the longer you go between updates the more chances things will break
<DC-IRC>
<infinity_q> yup LOL
<DC-IRC>
<infinity_q> I think debian updates pretty well between Releases
<DC-IRC>
<infinity_q> as long as you don't directly go to sid
<DC-IRC>
<infinity_q> more like Bookworm -> Trixie -> Sid
<DC-IRC>
<amazingfate> I did do an update from debian old stable to sid, then my system was broken.
<DC-IRC>
<lanefu> Lol That's a pretty aggressive jump
<DC-IRC>
<lanefu> I used to like debian testing branch a lot as a compromise
<DC-IRC>
<amazingfate> Yeah I deserve it.
<DC-IRC>
<lanefu> Lol
<DC-IRC>
<lanefu> Btw I think there's newer blobs for rk3588 (1 month old) vs 2 month old in Armbians rkbin
JaceAlvejetti has joined #armbian-rockchip
<DC-IRC>
<infinity_q> you should try migrating between debian-based distros xD
<DC-IRC>
<infinity_q> I have directly migrated debian testing to kali before
<DC-IRC>
<amdbartek> Okay, gonna try out the image
<DC-IRC>
<amdbartek> The serial adapter I bought did not work, output was mangled, but I bought another one and it works
<DC-IRC>
<amdbartek> Think the old one couldn't handle the baud rate or something. Anyway, I'm downloading the image
<DC-IRC>
<lanefu> @amdbartek baud rate 1500000 make sure ground is attach, don't attach VCC
<DC-IRC>
<amdbartek> It was the adapter
<DC-IRC>
<amdbartek> on radxa the one I got was the one they said NOT to use
<DC-IRC>
<lanefu> gotcha yeah some of them don't handle that baud rate
<DC-IRC>
<lanefu> lol
<DC-IRC>
<amdbartek> the exact one I got is the one that was said not to be used lmao
<DC-IRC>
<amdbartek> I got the FT232RL or whatever and it works fine
<DC-IRC>
<amdbartek> Alright, it's flashing. I ended up removing the SATA SSD from my laptop too and putting in another NVMe one, that way I can't accidentally wipe it by tab-completing `/dev/sd*`. Modern problems require modern solutions haha
<DC-IRC>
<amdbartek> But on a serious note, it seems that it is stuck on just the green light. Let me try rebooting it
<DC-IRC>
<amdbartek> @lanefu yep, no boot and serial is garbage. On the old image, I could see it booting up and the login screen, everything worked
<DC-IRC>
<amdbartek> this one works
<DC-IRC>
<amdbartek> Does u-boot or whatever have a different baud rate or encoding?
<DC-IRC>
<mariob> is this a known issue with Armbian_23.5.5_Orangepi5_jammy_legacy_5.10.160_gnome_desktop on orange pi 5 *plus* ?
<DC-IRC>
<lanefu> stuff from armbian should be the rockchip default of 15000000 sometimes people try to lower the baudrater to 115200 to make it friendlier, but really makes it worse IMHO
<DC-IRC>
<amdbartek> Hmm, cause it's all garbage that comes through until Armbian actually boots. Like u-boot stuff is just question mark characters
<DC-IRC>
<efectn> You need to download orange pi 5 plus image
<DC-IRC>
<amdbartek> That's with `115200 8N1`, with `1500000 8N1` there are occasional bits that come through but nothing actually proper until Armbian boots
<DC-IRC>
<lanefu> ahhh yeah i think that's cuz of armbian's default verbosity
<DC-IRC>
<lanefu> if you boot `verbosity=7` in `/boot/armbianEnv.txt` you'll see more stuff
<DC-IRC>
<amdbartek> Should I do so with the new image?
<DC-IRC>
<lanefu> if you want
<DC-IRC>
<lanefu> mostly just wanted confirmation that it boots since I added that build ot armbian
<DC-IRC>
<amdbartek> Cause that new SE image doesn't seem to actually boot
<DC-IRC>
<lanefu> oh
<DC-IRC>
<amdbartek> that other one does
<DC-IRC>
<amdbartek> This is the only fully functioning one without the RAM issues and that
<DC-IRC>
<amdbartek> u-boot just sends garbage down serial so idk what's happening but once armbian actually boots I can log in or set it up
<DC-IRC>
<lanefu> yeah damn really need the uboot info
<DC-IRC>
<lanefu> blaming your uart still
<DC-IRC>
<lanefu> so not uboot garbage with that image from las tnight?
<DC-IRC>
<lanefu> let me get off mainline uboot i was a fool for trying i guess
<DC-IRC>
<amdbartek> Oh, it had garbage in it when u-boot is booting. But when the armbian boot log shows and the login shell, I can see everything and it works
<DC-IRC>
<amdbartek> like I can log in via serial into the Pi and do stuff
<DC-IRC>
<amdbartek> When it actually boots that is. That image from last night boots, but the one with "SE" in the name does not. And I definitely have no clue how to get the serial to work on u-boot. I tried various baud rates and encodings
<DC-IRC>
<lanefu> yeah it's the uboot logs that are more information
<DC-IRC>
<lanefu> that's probably 1500000
<DC-IRC>
<lanefu> anyway let me try some options
<DC-IRC>
<amdbartek> Don't know much about this stuff but maybe give the Radxa u-boot a try? I tried 1.5 Mbps baud and didn't work sadly
<DC-IRC>
<amdbartek> Don't know much about this stuff but maybe give the Radxa u-boot a try? I tried 1.5 Mbps baud and didn't work sadly on the armbian one
<DC-IRC>
<amdbartek> Don't know much about this stuff but maybe give the Radxa u-boot a try? I tried 1.5 Mbps baud and didn't work sadly on the armbian one, not sure about Radxa
<DC-IRC>
<lanefu> yeah goal was to use the mainline uboot since they added a real config for it
<DC-IRC>
<lanefu> anyway lemme toss a few combos at you if you dont mind
<DC-IRC>
<amdbartek> np. I can test
<DC-IRC>
<lanefu> just looking for "booted, didn't boot"
<DC-IRC>
<lanefu> yeah gonna say that you def need different uart 😛
<DC-IRC>
<lanefu> okay lemme send you ones that probably ownt work again 😛
<DC-IRC>
<amdbartek> alright, apparently a FT232RL UART is good but oh well
<DC-IRC>
<amdbartek> better than that CP2102 that showed JUST garbage
<DC-IRC>
<lanefu> i can say CH340 def works
<DC-IRC>
<amdbartek> or... it's me messing something up (like encoding), but no, it seems to work. Now that I have 2 UARTS I am going to plug both into my PC and login via serial lol
<DC-IRC>
<amdbartek> Ok, yeah. The CP2102 is the bad one
<DC-IRC>
<lanefu> have a hamme near by?
<DC-IRC>
<lanefu> lol
<DC-IRC>
<amdbartek> lmao
<DC-IRC>
<mariob> cp2102 doesn't support 1.5 mbaud
<DC-IRC>
<mariob> only cp2104 does
<DC-IRC>
<mariob> (from silabs that is)
<DC-IRC>
<amdbartek> yeah, found that out. idk why the FT232RL doesn't work with u-boot
<DC-IRC>
<mariob> ftdi has some other issues
<DC-IRC>
<mariob> cp2104 and CH340 are the only ones known to work good
<DC-IRC>
<mariob> with this
<DC-IRC>
<amdbartek> that's a bummer, I keep buying bad ones haha. I'm gonna stick with the FT232RL cause it works for actually inside the OS though
<DC-IRC>
<microlinux> The hw supports vulkan, and horribly based on panfrost dev response, so, they did not care on adding support for midgard altogether
<DC-IRC>
<microlinux> Also, not even android has blobs for vulkan on midgard T860
<DC-IRC>
<microlinux> So, no.
<DC-IRC>
<microlinux> Based on what panforst dev said, the only compelling hw for vulkan will be valhall
<DC-IRC>
<microlinux> Previous hw doesnt make sense for vulkan, even if it worked
<DC-IRC>
<microlinux> Performance wise
<DC-IRC>
<microlinux> They will support it down the road for bifrost and up, and we dont know which bifrost version
<DC-IRC>
<microlinux> Based on my experience, gpu performance on rk3399 It's severely constrained on ram frequencies
<DC-IRC>
<microlinux> Overclocking the gpu doesnt make any real effect, but ddr3 rk3399s like the T4 run at 1800 MT/S, giving 17% gain compared to lpddr4 rk3399s that run by default at 1600 MT/s
<DC-IRC>
<microlinux> The blobs on RK3399T make ram on lpddr4 to run at 666 mhz, so 1332 MT/S, severely harming gpu performance
<DC-IRC>
<microlinux> I don't know if the new blobs would actuallmake it run to 1600 MT/S, so, to make it run on par with common lpddr4 rk3399s like the rockpro64
<DC-IRC>
<microlinux> On rk3399 at 1332 MT/S you get like 20 percent less performance on gpu workloads
<DC-IRC>
<microlinux> So, huge disadvantage
<DC-IRC>
<microlinux> Based on what LC guy said, lpddr4 on rk3399 was mostly a hack, since the IP of the ram controller was meant for ddr3, that's why lpddr4 rk3399s run at lower freqs by default
<DC-IRC>
<microlinux> Also, for some reason, evennwith ATF, rk3399 lied to me on rockpro64. I am a bit disappointed there
<DC-IRC>
<microlinux> Passing sbc bench showed me that my a72 cores were not running at 2.4 ghz
<DC-IRC>
<microlinux> So, I don't have any clue why that happened, on manjaro it was clear that they use blobs in uboot, but on armbian, my rockpro should not have lied to me.
<DC-IRC>
<microlinux> If you any point here, would be cool to know @rpardini
<DC-IRC>
<microlinux> On rk3399t at 1332 MT/S you get like 20 percent less performance on gpu workloads
<DC-IRC>
<rpardini> No further questions.
<DC-IRC>
<lanefu> @TheBug I tried to commit all the copy pasta crimes i could from @rpardini odroidm1 PR, for nanopi-r5s but looks like uboot requires trying harder