tilpner has quit [Read error: Connection reset by peer]
tilpner has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
stiell has joined #nixos-aarch64
stiell has quit [Ping timeout: 246 seconds]
stiell has joined #nixos-aarch64
stiell has quit [Ping timeout: 258 seconds]
stiell has joined #nixos-aarch64
<colemickens>
samueldr: I'm thinking about taking some time to contribute my u-boot changes so that using the pi4 normally works with the rpi-uboot bootloader, since we sorta just have the image working now. I'm thinking about also seeing if I can "move" the image to using the bootloader-generation process (de-dupe) and move it out-of-tree to nixos-hardware? We could remove what's there now, or deprecate it and point people to
<colemickens>
nixos-hardware? wdyt?
<colemickens>
it'd be cool to whip that into shape for potential raspbian refugees
<samueldr>
the goal always has been to delete the raspberry pi 4 nix derivation
<colemickens>
I know
<samueldr>
(I'm agreeing I think)
<colemickens>
Okay!
<samueldr>
any effort towards ensuring sd_image works at the very least as an aarch64 stepping stone is welcome
<colemickens>
okay, I think what I have in mind jives with everything I've heard you discuss, and/or fits with what I feel like a good split of nixpkgs/nixos-hardware could be
rajivr has quit [Quit: Connection closed for inactivity]
Acou_Bass has joined #nixos-aarch64
<adisbladis>
I thought we were supposed to build native armv7 on the community builder?
<adisbladis>
What happened?
<sphalerite>
adisbladis: what do you mean?
<sphalerite>
as in what are you expecting concretely and how is that expectation not being fulfilled?
<adisbladis>
sphalerite: I expected `nix-build '<nixpkgs>' -A foo --argstr system armv7l-linux` to work
<sphalerite>
unfortunately no
<adisbladis>
Actual result: a 'armv7l-linux' with features {} is required to build '/nix/store/d437id9dxb8x0d1r00chcicp1zc2adbi-bootstrap-stage0-stdenv-linux.drv', but I am a 'aarch64-linux' with features {benchmark, big-parallel, gccarch-armv8-a, kvm, nixos-test}
<adisbladis>
Ugh... Idk what to do
<sphalerite>
you could pass --extra-platforms armv7l-linux but that also wouldn't really help
<adisbladis>
qemu-user is too slow to be a realistic option
<sphalerite>
(that will make nix just think "ok I'm an armv7l-linux as well"
<sphalerite>
That doesn't work however, because of tools using uname and thinking "oh I'm aarch64 ok"
<sphalerite>
What you can do is make a hardware-accelerated VM that has aarch64 disabled
<adisbladis>
Yeah... I think I'd rather try to find some armv7 cloud vendor for now
<adisbladis>
Is there one?
zupo has quit [Ping timeout: 256 seconds]
<sphalerite>
don't know if scaleway still offer theirs
<sphalerite>
I think the VM approach is more promising though
<sphalerite>
based on my scaleway experience, you might as well just make your own little $SBC cluster
<adisbladis>
sphalerite: I can't
<sphalerite>
srk: what was your 32-bit ARM cluster made of again?
<adisbladis>
I don't have a home :P
<adisbladis>
Nowhere to put anything
<sphalerite>
adisbladis: or ask srk if you can borrow his :ppp
<sphalerite>
(I don't know if it still exists)
<adisbladis>
Hm, now that r-ryantm is off the main nix-community build machine I might just enable qemu-user there for now
<adisbladis>
We should have some spare capacity
<sphalerite>
Why not use VMs on the nix-community machine?
<sphalerite>
it'll be a lot faster.
<adisbladis>
I lost all my energy to do anything remotely complicated atm
<gchristensen>
the armv7 cloud vendors are miserable
<gchristensen>
adisbladis: what are you trying to build?
<adisbladis>
gchristensen: Things for my remarkable
<gchristensen>
ah
<gchristensen>
armv7 is completely exhausting to me
<adisbladis>
Yeah :/
<adisbladis>
Tbh every time I get into anything cross I want to flip a table
<adisbladis>
There is always something broken
<adisbladis>
But I completely understand their SoC choice
<adisbladis>
There doesn't seem to be much in the way of aarch64 for the purpose
<gchristensen>
even rpi is aarch64 now
<gchristensen>
but that is probably a different enough target
<adisbladis>
Remarkable has special considerations, like e-ink controllers
<adisbladis>
I wish I had one of my old armv7 phones handy, but it's all in storage :/
<gchristensen>
there are probably 1000+ developers who would pay for an armv7 "cloud" but my impression is anyone who knows anything about it doesn't want to get near supporting such a thing
<clever>
i'm having trouble building anything for armv6l here
<adisbladis>
Lol, it gets worse
<clever>
cross compile fails with one error, native fails with another
<adisbladis>
gchristensen: Oh yes, no one in their right mind would offer that as a commercial service :P
<clever>
and i'm also having trouble finding an old nixpkgs that still works, because dezgeg deleted the bootstrap files
<gchristensen>
$1,000,000/day
<sphalerite>
clever: redo the bootstrap using debian tools or similar?
<sphalerite>
or cross-compiled stuff
<sphalerite>
or is it broken to the point that you can't build busybox?
<clever>
sphalerite: one of the native faults, is that the linker during a gcc build just silently exits with code 1, and no error
<sphalerite>
oh nice
<clever>
the older nixpkgs fail, because it cant fetch the bootstrap tools+busybox from dezgeg's server (404)
<sphalerite>
hmmm I might still have some of those ancient bootstrap tools lying around somewhere
<clever>
i could maybe try a new bootstrap-tools with an old nixpkgs...
<sphalerite>
or that
<sphalerite>
funnily enough, the place that I might have these ancient bootstrap tools is on the storage I was considering wiping earlier.
<clever>
in my case, the current goal is to get wpa_supplicant running on a pi0
<clever>
currently i'm waiting on a native gcc build
<Ericson2314>
sphalerite: i think we're getting closer
<craige[m]1>
Thanks for the monthly report samueldr++ - great update!
<{^_^}>
samueldr's karma got increased to 318
<samueldr>
you're welcome
<samueldr>
so many little things, some I worked not exclusively during that month, just fell together
<samueldr>
I didn't even plan for the qcacld-2.0 stuff to be done :)
<samueldr>
the solution just fell in my lap
* craige[m]1
needs to write a karma bot where "++" transfers some for of Crypto to to the recipient.
<samueldr>
some good ol' AES-GCM
<samueldr>
or the classic ROT13?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<flokli>
so turns out, I finally managed to assemble the kobol64
<flokli>
It's a neat device. A lot of blinking LEDs, and a pretty crazy baudrate :-D
<flokli>
Armbian 20.11.6 Focal is a bit… eww
* samueldr
looks at box
<flokli>
"ohai, you seem to be running in .de, for sure you'll want either de_DE.UTF-8 or hsb_DE.UTF-8"
<samueldr>
I didn't even start yet :/
<flokli>
and I also configured Europe/Berlin for you as TZ
<flokli>
Well, it boots, for much I can tell
<samueldr>
maybe mine is DOA!
<flokli>
make sure the landline power is connected
<flokli>
mine was a bit grumpy, starting via battery
<flokli>
I didn't realize it at first
monk has left #nixos-aarch64 ["Error from remote client"]
<flokli>
w.r.t. getting NixOS there, I'm not wondering whether I should fix broken cross and assemble a separate sdcard with it, or just install nix on that Ubuntu, and build there :-D
<samueldr>
angerman has something IIRC
<samueldr>
though, I sure would say "fix cross"
<samueldr>
or at the very least, start with a cross from early january
monk has joined #nixos-aarch64
<flokli>
samueldr: define that something that angerman has
<clever>
firmware for /nix/store/mjcj4l6hilp6ffbx06nhqmnk7f6v88n5-modules/lib/modules/5.4.72-v7l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko: brcm/brcmfmac43012-sdio.bin
<clever>
sphalerite: have you seen this error?
<samueldr>
flokli: armbian is the official location of vendor patches for mainline IIRC
<samueldr>
which, if I get right, means they're not really "shipping vendor kernels" or anything BSP
<samueldr>
better than many RK3399 boards
<flokli>
true
<samueldr>
but yeah, a lot of patches around
<samueldr>
IIRC for u-boot too
<flokli>
100
<samueldr>
u-boot IIRC manages the delayed start of the disks
<samueldr>
since otherwise the current spike will be too high
* flokli
looks at the single ssd currently plugged in
<samueldr>
TOO HIGH I said
<flokli>
all the way up to the moon :-)
<samueldr>
but yeah, I figure you understand it would be about 5 3.5" hungry hungry hippos^W HDDs
<flokli>
ack
<flokli>
"hey, let's start spinning some rust. all of it"
<samueldr>
tbf, I did do some RK3399 work recently that would allow using the Helios64 as a mass storage device via USB
<samueldr>
or any other fun things you can think of via usb
<sphalerite>
flokli: oh yeah, assembly is a bit of a pain. angerman's thing worked fine for me, though I ended up nixifying the kernel config a bit more.
<sphalerite>
I should probably publish what I did
<sphalerite>
flokli: what I did includes a btrfs-based image that you can just plonk on the eMMC, ISTR you like btrfs ;)
<flokli>
as for the custom unit invoking ethtool, that could probably just be a TransmitChecksumOffload=false in a .link file matching the interface name/driver/whatever
<samueldr>
oh
<samueldr>
mainline linux *may* have an issue with its MMC driver
Darkmatter66 has quit [Ping timeout: 276 seconds]
<samueldr>
I've hit it on different platforms
<samueldr>
it seems to happen on x86_64 too
<samueldr>
but it is extremely inconsistent
<samueldr>
what this does is until the block device is shown, it turns it off and on again
<samueldr>
(hi, I'm not sphalerite)
<flokli>
heh
<samueldr>
had to do the same for asus-dumo
<samueldr>
my gut feeling is that it's highly dependent on the exact mmc chip
<samueldr>
that some are more marginal than others
<samueldr>
and that *something* in the driver exacerbates the issue
<sphalerite>
yeah. I initially discovered this "fix" on my chromebook, where it can take >5 minutes of attempts for the emmc to appear… thankfully it's nowhere near that bad with the helios64 and often just works without that script needing to do any work at all
<samueldr>
first time I saw that issue was on the pinebook (A64) (not pro), with one specific MMC chip
<samueldr>
but at the time I just assumed the chip wasn't supposed to work in it
<sphalerite>
flokli: oh yeah the link file is a good idea, I think I noticed that udev could take care of it at some point and then forgot again.
<flokli>
hmm, the RK3399 can't do kvm, right?
<samueldr>
it can
<samueldr>
note that you may have to tell qemu to stick to either the two fast, or the four small cores
<samueldr>
not sure anything changed, but qemu couldn't deal with all of them at once at some point
<flokli>
I think I first need to tell armbian/Ubuntuarmbian to build a kernel with support compiled in
<flokli>
sigh
<samueldr>
taskset -c 0-3 or 4-5 IIRC
<sphalerite>
why do kvm on ubuntu when you could install nix and get your nixos image done as quickly as possible? ;)
<andi->
flokli likes to take detours and waste time on yet another SBC that ends up collecting dust :P
<samueldr>
ugh
<flokli>
I installed nix on it
<samueldr>
store them in boxes
<samueldr>
no dust
<flokli>
But I need qemu to build the disk image
<flokli>
Or to run a VM test
<andi->
I think I built my image with binfmt
<flokli>
I might just abuse some other aarch64 box or binfmt with that
<samueldr>
or cross-compile from ~january 5th nixpkgs