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>
<Tenkawa> linux-5.10-gen-rkr3.4 is a radxa specific repo thing...
<Armbian-Discord>
<Tenkawa> so its their naming conventions
<Armbian-Discord>
<Tenkawa> just like they formerly were using stable-5.10-rock5
<Armbian-Discord>
<Tenkawa> however that one has long since stopped being updated
<Armbian-Discord>
<c0rnelius> really poor naming... they should have just named it radxa-5.10.y or something to that effect.
<Armbian-Discord>
<Tenkawa> Yeah... not sure what their intent was with the naming
<Armbian-Discord>
<Tonymac32> Lolz
<Armbian-Discord>
<c0rnelius> my guess would be generation rockchip release 3.4
<Armbian-Discord>
<Tonymac32> Lindroidixa
<Armbian-Discord>
<rpardini> What I meant is... is there a source for original rk tree somewhere? I wanna split off Radxa's patches from rk base
<Armbian-Discord>
<rpardini> maybe I'm overcomplicating. say, looks like dd57ee4c1f3e4b974fedb5f452f2c618be87ae28 might be a good marker, "Radxa's stuff after this"
<Armbian-Discord>
<rpardini> so radxa tree has 228 patches of which only 108 (!) are Radxa proper, but that's still manageable.
<Armbian-Discord>
<rpardini> we've the Xunlong opi5 patches in, DT, a few drivers.
<Armbian-Discord>
<rpardini> I've a try with the Khadas edge2 tree, same stuff except a lot of mcu stuff taking over, of course.
<Armbian-Discord>
<rpardini> then again, hate wasting time on vendor shit.
<Armbian-Discord>
<rpardini> how goes with the mainline rk3588 tryouts @c0rnelius ?
<Armbian-Discord>
<c0rnelius> @rpardini encountered a bug and then squashed it and then encountered another. 🙂 slowly it goes. plus I'm not in a super rush here.
<Armbian-Discord>
<rpardini> any sign of ethernet working?
<Armbian-Discord>
<c0rnelius> @rpardini i don't have any 3588 units I was just looking at it on a code level, but there was a ethernet patch submitted and accepted last I saw for the 3588.
<Armbian-Discord>
<rpardini> we've the same problem, lack of units.
<Armbian-Discord>
<c0rnelius> yeah... hopefully be able to get one next year.
<Armbian-Discord>
<c0rnelius> i have no practical reason to own a 3568 but I would eventually like to get one of those.
<Armbian-Discord>
<rpardini> 66/68 are sweet mainline bliss. ethernet, pcie nvme, stable if cooled, I'm happy.
<Armbian-Discord>
<rpardini> I dont care about hdmi, gpu, etc.
<Armbian-Discord>
<c0rnelius> nice. I don't care about hdmi either.
<Armbian-Discord>
<c0rnelius> only when I'm using the board as a kodi player or something like this.
<Armbian-Discord>
<Tenkawa> ethernet working on which?
<Armbian-Discord>
<c0rnelius> mainline and 3588 I believe
<Armbian-Discord>
<Tenkawa> As far as I have heard it is still doing nothing but the serial console on mainline
<Armbian-Discord>
<Tenkawa> still no more progress yet
<Armbian-Discord>
<Tenkawa> I'd like to test something more and start working on mainline myself (If its realisticly being developed) too since I have two machines to use.
Armbian-Discord has quit [Remote host closed the connection]
<Armbian-Discord>
<amazingfate> They may update it to rkr3.5 in the future.
<Armbian-Discord>
<Tenkawa> How far off do you think it has "diverted" since it was branched? would it even run on the Rock5 in its current form? The difficulty I have with the way this is being handled is there are "too" many divergant paths being taken with no real plan being communicated to the community om which codebase we should be following
<Armbian-Discord>
<amazingfate> This is the original sdk released by rockchip, all the downstream rockchip boards create their own branch based on this official sdk.
<Armbian-Discord>
<Tenkawa> Nod. I agree.. I'm illustrating the need for each vendor to be more clear about what they are using.
<Armbian-Discord>
<amazingfate> The branch name of radxa is clear, just the same as the sdk tag. For other boards we have to ask their developer or compare the source code with rockchip's sdk.
<Armbian-Discord>
<Tenkawa> No.. Radxa has already used 2 different git sources and switched midstream
<Armbian-Discord>
<Tenkawa> stable-5.10-rock5 and rkr3.4
<Armbian-Discord>
<amazingfate> I mean the new branch rkr3.4.
<Armbian-Discord>
<Tenkawa> But that goes back to my original point... communications
<Armbian-Discord>
<Tenkawa> or lack of
<Armbian-Discord>
<Tenkawa> Having all of these out there without knowing which one is the "right" branch.. its a dice roll
<Armbian-Discord>
<amazingfate> @RadxaYuntian is maintaining the source code of radxa. I got these info I know from him.
<Armbian-Discord>
<Tenkawa> I as well.,,
<Armbian-Discord>
<Tenkawa> I'm also very picky on documenting everything because of my past career....
<Armbian-Discord>
<amazingfate> This should be a basic knowledge in rockchip legacy world. Rockchip releases new updated version of it's sdk and updates the code tag. If we pay attention to the updates from rockchip, every downstream update will be reasonable.
<Armbian-Discord>
<Tenkawa> Ok.
<Armbian-Discord>
<Tenkawa> Time to get ready to rebuild a RK3399 and 2 BCM2711's... this should be an "interesting" day.
<Armbian-Discord>
<Tonymac32> I can't wait for this nonsense to be done with. Rockchip legacy needs thrown in a dumpster, lit on fire, and sunk into the ocean
<Armbian-Discord>
<Tonymac32> What a joke that entire code base is
<Armbian-Discord>
<amazingfate> lol
<Armbian-Discord>
<amazingfate> Although it sucks, it is the only kernel that has full multimedia support.
<Armbian-Discord>
<TheBug> Interesting that was likely 100% unintentional and happened during review of tickets, please unset/set back if appropriate
<Armbian-Discord>
<Tonymac32> ROFL
<Armbian-Discord>
<Tonymac32> Ok
<Armbian-Discord>
<TheBug> Sorry about that, if it was me it was a mistake :/
<Armbian-Discord>
<Tonymac32> No worries I wanted to make sure
<Armbian-Discord>
<Tonymac32> It needs refactored before next release, Roman took care of/is taking care of the laughable patch set we got handed for the Rock Pi S
<Armbian-Discord>
<TheBug> Thanks for doing that as i wouldnt have caught it for a while
<Armbian-Discord>
<Tonymac32> The station RK3328 I think I'll just delete since it lives in Oleg's kernel
<Armbian-Discord>
<Tonymac32> Helios64 should be looked over by the man of the sea
<Armbian-Discord>
<TheBug> wait, I know your address I think....
<Armbian-Discord>
<TheBug> plots to have door dash delivery several cases of beer
<Armbian-Discord>
<Tonymac32> 🤣🤣
<Armbian-Discord>
<ManoftheSea> I'm working on it.
<Armbian-Discord>
<ManoftheSea> Looking at u-boot presently, then going to figure out the difference between the old added dts and the now mainline 6.1 dts
<Armbian-Discord>
<ManoftheSea> okay, I don't know what I'm doing. trying to port the helios64 patch to u-boot master, and getting an error from binman.
<Armbian-Discord>
<ManoftheSea> binman: Node '/binman/simple-bin/blob': Offset 0x2e000 (188416) overlaps with previous entry '/binman/simple-bin/mkimage' ending at 0x2e800 (190464)
<Armbian-Discord>
<Tonymac32> That shouldn't happen
<Armbian-Discord>
<Tonymac32> Hmmm
<Armbian-Discord>
<ManoftheSea> I copied over a "PAD_SPL" config option from rockpro64's defconfig, and it got past that point.
<Armbian-Discord>
<Tonymac32> Ahhh ok
<Armbian-Discord>
<ManoftheSea> what is going on with u-boot patches in armbian/build? There's 3 different versions of u-boot as well as a rockchip64, a rockchip64-2022.04...
<Armbian-Discord>
<ManoftheSea> And here I'm trying to patch against 2023.01-rc4
<Armbian-Discord>
<ManoftheSea> looks like I want u-boot-rockchip64, but I don't yet know what version of u-boot that builds against.