<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
<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)
<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
<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>
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