srk has joined #nixos-aarch64
efraim has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
efraim has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
tilpner has quit [Quit: WeeChat 2.3]
tilpner has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo_ has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tilpner has quit [Quit: WeeChat 2.3]
zupo has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
<makefu> samueldr: but it is something alright
<makefu> lets hope the supplier delivers at some point something working
<samueldr> yeah, the libre.computer engineer is booking time with the firefly engineer to hash things out
<samueldr> though, while I was asleep, another user figured out how to build it using the binary components from rockchip
<samueldr> I might try it this way and compare
<makefu> he is using the tbl and trusted binaries from rkbin, right?
<samueldr> yeah
<samueldr> ddr training, trust and miniloaders from rkbin
<makefu> i am pretty sure that he is using the prepared "linux-sdk" which contains the config for the rk3399-roc-pc
<samueldr> I wasn't able to boot using the u-boot spl, but AFAIUI (might be wrong) it doesn't handle (lp)ddr4 at all
<makefu> for uboot they use firefly-rk3399
<samueldr> I think the user is not using linux-sdk at all
<makefu> https://github.com/FireflyTeam/manifests/ - this is their sdk based on repo
<makefu> it wil lfetch the "correct" stuff for each platform
<samueldr> they shared another thing earlier, which makes me think that, while they are indeed using the firefly u-boot fork, they are building it in another way
<makefu> that may be true
<samueldr> except that many repos don't have the right branches available yet :/
<samueldr> (I looked)
<makefu> the "repo" thing also checks out some weird refs, not branches
<samueldr> yeah
<samueldr> that's what I meant
<samueldr> (repo is a tool used with android to fetch all things)
<samueldr> still, looks like firefly is in my list of bad mfgs :/
<makefu> yeah, i've seen it first there and essentially it replaces git submodules
<samueldr> submodules might be newer than repo
<makefu> wow
<makefu> haha
<makefu> firefly has everything open-sourced, however it is a real mess in that state
<samueldr> "repo" has their v1.0 tagged on a 2008 commit
<samueldr> submodules were added in 2007
<makefu> it looks like firefly just cloned everything from rockchip and started adding their weird patches
<makefu> and rockchip was using repo, so they also continued using it
<samueldr> and the v1.0 of repo is definitely not its first use
<samueldr> makefu: exactly
<samueldr> least amount of effort to get the boards out it looks like
<makefu> yep
<samueldr> and zero mainlining effort :/
<makefu> yeah, so sad
<makefu> at least rockchip tries somewhat to get the basic boards upstream
<samueldr> I'm unsure, but I think firefly even botched it harder than expected
<samueldr> the board *should* in theory allow dual output, hdmi + dp via usb-c
<makefu> wow, really?
<samueldr> but their ubuntu build cannot do it
<samueldr> one at a time
<makefu> that sucks
<samueldr> yeah, I hope it's only their software which sucks
<samueldr> also, I'm not sure, but I think they didn't bother adding the SPI nor flash support to their u-boot fork
<samueldr> mainline kernel starts, but I'm unsure whether it fails, hangs or I have misconfigured the console for the serial (though serial output is fine)
<samueldr> once I have u-boot figured out in some way, it'll be the next thing to do
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<makefu> samueldr: i am sure that the uboot needs the same tweaks as the kernel itself (15000000 baud and some other console magic
<samueldr> I have no issue with getting u-boot serial
<samueldr> I was talking about having a *built* u-boot
<makefu> ah!
<makefu> for mainline kernel you will also most likely need the kernel options as i did for my rk3399 board. at some point the serial console stopped without these tweaks
<samueldr> yeah, I used the same serial command line option and got serial output from the kernel
<samueldr> but it seemingly hangs
<samueldr> haven't taken a look since
<makefu> maybe you could check the downstream image, this is where i got the parameters from ( cat /proc/cmdline )
<makefu> anyway, the essence is that there are just so damn many software issues with the boards it is not even funny anymore
<samueldr> yeah, I'm stuck at u-boot since it's highly annoying having to swap sd cards only to boot nixos :/
<samueldr> same, knowing all that I'd never recommend a firefly board
<samueldr> good thing mine's going through another team which hopefully will rectify things
<makefu> hopefully!
<samueldr> for their non-rockchip boards, they've been doing good work (allegedly, haven't got any of them yet)
<makefu> which are these?
<makefu> https://libre.computer/products/boards/ <- software: average
<makefu> well that is true
<samueldr> I meant both of the allwinner and amlogic boards
<makefu> i am still looking for a decent working sbc with pcie/m.2 and the rockpro64 looks most promising. however it is rockchip rk3399 again and i am unsure if i would want that pain again
<samueldr> lopsided98 might have an opinion
<makefu> ah samueldr, maybe you could try the rockpro64 bootloader
<samueldr> yes tried it :)
<samueldr> that's the one that got the furthest in my tries
<samueldr> without corruption
<makefu> ahhh too bad than this didn't work out
<makefu> wow nice!
<makefu> so you really have a working u-boot (with two blobs in it but still)
<samueldr> didn't work, couldn't read from mmc
<samueldr> but there I think a big issue is how I don't really know what I'm doing :)
<makefu> samueldr: i have the exact same problem. often times i feel like a drunken monkey on a keyboard trying to get the banana
<samueldr> I have a decent feeling of what's going on, but without a working build from the downstream firefly fork, I can't work backwards into filling in some deep assumptions
<lopsided98> makefu: I've had a pretty good experience with the rockpro64
<lopsided98> I haven't used PCIe on it though
<samueldr> still waiting on a pinebook queue thing so to get one :/
<samueldr> (pinebook and rockpro)
<samueldr> to (hopefully) get cheaper shipping by combining
<lopsided98> I've heard that there are some compatibility issues with certain PCIe devices, but I think storage devices generally work
<samueldr> from what the libre.computer engineer said previously, I think it's RK3399 and not their board, things like GPU will fail due to *something* lacking, which makes it only be able to address like 32MB
<samueldr> though otherwise, drivers nonwithstanding, many PCIe things will work
<samueldr> curious though if it's an RK3399 issue or their board
<samueldr> lopsided98: were you able to test HDMI + DP out?
<samueldr> oh it doesn't have hdmi at all
jackdk has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 245 seconds]
<flokli> orr, already ordered a rockpro64 to finally fix my halfway-broken nas solution. then I saw that the only kernel mainlining work seems to be done by an hobbyist in his free time
<samueldr> AFAIK RK3399 itself has a good mainline support due to the work google put in for their chromebooks
<samueldr> at least, from what I could gather
<flokli> yes
<flokli> According to pine64's cancellation conditions, I contacted them, wrote I really like the hardware, but given they don't seem to care at all about mainlining their stuff, I can't really buy this
<samueldr> yeah, pine themselves don't seem to care :/
<flokli> they replied they'll refund it. I asked back about any comment wrt the mainlining efforts, they then simply replied "We have no comments of your feedback"
<samueldr> their A64-LTS also has the same issue, mainlining efforts by users
<samueldr> that's what's killing ARM
<flokli> why are these vendors so crappy? Why do hobbyists need to clean up the mess vendors leave their stack with in their free time?
<samueldr> either you have (allegedly) good upstreamed hardware in server-class pricey hardware, or have the crappy non-mainline pump and dump schemes
<andi-> because a) is it expensive b) they might not have the funding / motivation to upstream it
<flokli> on that specific board, console, sdcard, pwm, flash frequencies etc. seems to be broken, according to https://github.com/ayufan-rock64/linux-mainline-kernel/commits/master
<samueldr> I'd be ready to pay "good computer prices" for something
* flokli nods
<andi-> most of us probably
<samueldr> e.g. look at the NUC from intel, make something as pricey, use some more powerful hardware, same size
<samueldr> or even a full µATX or whatever is the norm right now
<andi-> but the way I see most of the devices is that they are just a weekend-project device that most people tinker with to get going and never touch again or just buy and almost not use?
<samueldr> but don't put a dinky allwinner :/
<samueldr> yeah, SBCs seem to fall under that use case, or users fine with using whatever non-mainline sdk to just do their dumb thingy
<andi-> they are mostly trying to get their share of the RPi market... But they can't properly compete with them in terms of software quality / freedom
<flokli> as long as the vendor provides some some armbian sdcard images that seem to work, every's happy :-/
<samueldr> (software quality / freedom is debatable for rpi)
<andi-> (I agree, but IMO still bettere there then on many other devices given the state of the kernel ports)
<samueldr> the sheer mass of their user base probably is a big reason for the mainline availability, but mainline isn't "there" either :/
<samueldr> yeah
<samueldr> I think I'll end up with a chromebook type device for a "good" RK3399 experience :/
<samueldr> (google completely bypasses rockchip's bootloading processes)
<samueldr> there was recently a merge in u-boot for a full proper u-boot for those boards, well, one of them
<andi-> I am not a very big fan of the way ARM works.. Selling licenses to some CPU design just creates the current scattered device market.. I am skeptical if RISC-V will do any better at that...
<samueldr> I'm thinking RISC-V risks (heh) having one major RISC-V-based manufacturer running ahead of the others, with proprietary additions
<samueldr> like it's already happening with ARM
<andi-> I just hope it will be more like CPU flags/features that are opt-in on-top of the base set but given how modular the entire thing is I am not convinced that will work
<samueldr> IIRC from initial reading, integrators can make their cores any way they want, and the "open" label doesn't apply to whatever they add
<samueldr> though, I'd be glad to be wrong
<andi-> time will tell
<makefu> meanwhile i am happily deploying a raspi1 with 256mb ram (and 4g swap). it is something i guess
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<makefu> btw if anyone is interested, long time ago i wrote about a home-made KVM switch with a cheap av-grabber and a home-made keyboard-passthrough controller https://euer.krebsco.de/a-software-kvm-switch.html . the whole setup just got a lot easier now that there are integrated crappy HDMI grabbers for around $12 . the image is essentially PAL but it is enough to see something. plus you do not need a